Willkommen |
|
myGully |
|
Links |
|
Forum |
|
|
|
|
|
20.03.13, 12:57
|
#1
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Mau Mau
Hallo liebe Community,
ich hoffe doch ihr könnt mir helfen. War mir erst nicht sicher wo genau ich mein Problem äußern soll, aber da es grundsätzlich um Netzwerksicherheit geht denke ich mal dass ich hier richtig sein sollte.
Wir haben die Aufgabe bekommen das allseits bekannte Kartenspiel Mau-Mau so zu programmieren, dass es möglichst sicher ist und es keinem möglich ist zu mogeln.
Ein Spieler ist gleichzeitig der Server und andere Clients verbinden sich mittels Zertifikat mit dem Server(2-5 Spieler inklusive Server). Die direkte Kommunikation zwischen den Clients soll nicht möglich sein, sondern nur über den Server. Sollte dieser die Kommunikation nicht lesen dürfen, könnte man dies ja mit Public und Secret Keys (PK,SK)realisieren(falls nötig).
Nun zur Frage an sich:
Wie kann das mischen der Karten realisiert werden, ohne dass irgendein Client weiß welche Karten sich wo im Deck befinden oder welcher Spieler welche Karte zieht?
Unsere Ansätze:
Der Server permutiert (mischt) das Deck, verschlüselt die Permution mittels MAC und schickt einen teil des schlüssels an alle raus (am ende kann nachfolzogen werden ob alles mit rechten dingen zuging). -> Problem: Server(Spieler1) kennt die Reihenfolge der Karten bzw kann sie beliebig anordnen. -> mögliche Lösung:
Server schickt gemischtes Deck an Spieler 2. Dieser mischt erneut und schickt das neue Deck verschlüsselt an Spieler 3. Dieser mischt(nach entschlüsselung über kommunikation mit hilfe pk sk mit spieler 2 ) erneut, schickt weiter bis zum letzten Spieler, der wiederum mischt und dieses Deck an den Server schickt. Dieses zuletzt gemischte Deck wird an alle geschickt damit jeder ein "spielbares Deck" hat.
-> FRAGE: Wie kann eine gezogene Karte nun wieder "entschlüsselt" werden , OHNE dass ein Spieler weiß welche Karte gezogen wurde oder weiß in welcher Reihenfolge die karten im Deck liegen???
Ich hoffe ihr habt verstanden was ich möchte. Falls ich mich zu unklar ausgedrückt habe fragt einfach nach. Ich beantworte Fragen gerne (soweit möglich ) und freue mich über alle Anregungen, Hinweise oder auch Lösungsansätze.
LG
Hagemann
|
|
|
20.03.13, 16:27
|
#2
|
Banned by himself
Registriert seit: May 2009
Beiträge: 2.938
Bedankt: 2.106
|
Warum willst du den Clients überhaupt mitteilen wie das Deck gemischt wurde ?
lass das am Server. Hebt ein Spieler ab bekommt nur dessen Client die gezogene Karte zugeschickt und fertig.
der Server speichert wer welche Karten hat und überprüft das beim ablegen einer Karte der Spieler die Karte tatsächlich in der Hand hat.
mehr kommunikation braucht das ganze Spiel nicht wirklich, und dann lässt sich auch nicht schummeln
edit: wenn dus übertrieben sicher machen willst überprüfst du noch jedesmal beim ablegen / ausgeben einer Karte die Handkarten der anderen Spieler und das Deck ob die Karte vorkommt, so müsste man beim "hacken" des Servers gleichzeitig mehr als einen Speicher ändern
__________________
Lebt wohl war mir eine Freude über viele Jahre mit euch, zumindest mit jenen die mich nicht des trollens bezichtigten...
|
|
|
20.03.13, 16:29
|
#3
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
prinzipiell hast du ja recht, wenn wir einen dedizierten server nutzen dürften
die sache ist aber dass der server gleichzeitig ein spieler sein soll
hört sich zwar komisch an aber so wurde uns die aufgabe gestellt
klar wäre es einfacher hätten wir einen server auf den man sich verlassen könnte
da wir das aber selber programmieren sollen kann man das ja stark beeinflussen sollte man selber der server sein
edit:
um es vielleicht leichter verständlich zu machen
im grunde soll es wie ein reales mau mau spiel laufen
5 spieler
einer mischt und verteilt die karten, spielt gleichzeitig aber natürlich mit
da überprüfst du ja auch nicht immer das deck ob das noch geht da du dadurch schummeln kannst
genau so soll es an sich im netzwerk programmiert werden
ein spieler übernimmt zwar die spielleitung, darf aber bis zum ende eines spieles nicht ständig überprüfen ob es diese karte noch im deck gibt
klar kann sich jeder spieler merken welche karte bereits gespielt wurde
aber genau wissen wo sich welche unausgespielte karte gerade befindet darfst du nicht wissen
|
|
|
20.03.13, 17:10
|
#4
|
Hinter dir!
Registriert seit: Apr 2010
Beiträge: 1.125
Bedankt: 487
|
Ihr könnt es so machen, wie thyriel es schon schrieb, dann müsst ihr die Übertragung nicht verschlüsseln.
Der Server weiß ja, dass er der Server ist und übernimmt diesen Teil dann automatisch.
Hier muss man nur wegen der Speichermanipulation aufpassen.
|
|
|
20.03.13, 17:23
|
#5
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
ich glaube ich werde nicht richtig verstanden
gut vielleicht sind das noch zu wenig informationen
aaaaaallllllsooooo:
wir sollen das spiel selber programmieren
sind 3 gruppen die an sich für sich selber programmieren sollen
die versionen sollen untereinander kompatibel sein, was aber ersteinmal irrelevant ist
sprich jeder programmiert seinen server anders
ich versuche es mal so zu beschreiben
wir zwei spielen gegeneinander (real)
ich hole ein kartendeck raus sage es sei gemischt und verteile die karten
würdest du mir vertrauen?
am liebsten würdest du doch auch nochmal mischen wollen um sicher zu gehen dass die reihenfolge der karten nicht von mir manipuliert wurde
und die gleiche situation ergibt sich doch im netzwerk
|
|
|
20.03.13, 17:37
|
#6
|
Hinter dir!
Registriert seit: Apr 2010
Beiträge: 1.125
Bedankt: 487
|
Zitat:
Zitat von Hagemann
ich hole ein kartendeck raus sage es sei gemischt und verteile die karten
würdest du mir vertrauen?
|
Vielleicht.
Zitat:
Zitat von Hagemann
am liebsten würdest du doch auch nochmal mischen wollen um sicher zu gehen dass die reihenfolge der karten nicht von mir manipuliert wurde
und die gleiche situation ergibt sich doch im netzwerk
|
Macht der Server das automatisch (also das Programm ohne Benutzeraufforderung), sollte man dem schon vertrauen können.
Egal wer die Karten mischt, wenn man weiß wie, kann man es beeinflussen.
Mischt hier jeder einmal die Karten, kann derjenige, der sie zuletzt mischt, sie einfach so sortieren, wie er es möchte (wenn man halt weiß wie).
Jeder Client könnte dem Server aber eine zufällige Zahl übermitteln, der diese nach einer bestimmten Formel zusammenrechnet und die Karten entsprechend mischt.
Bei jedem Zug kann der jeweilige Client dann überprüfen, ob es mit seiner Zahl möglich wäre, dass diese Karte gezogen wurde.
Das wäre jetzt die sicherste Methode zum Mischen, die mir einfällt.
|
|
|
20.03.13, 17:52
|
#7
|
Banned by himself
Registriert seit: May 2009
Beiträge: 2.938
Bedankt: 2.106
|
Wenn der Server mit einem Spieler ident ist dann lässt sich manipulation sowieso nie gänzlich ausschließen. (RAM auslesen und manipulieren)
Zitat:
die versionen sollen untereinander kompatibel sein, was aber ersteinmal irrelevant ist
|
Das ist alles andere als irrelevant.
Das bedeutet das euch die Netzwerkkommunikation vorgegeben werden muss, sonst können die verschiedenen Programme nicht miteinander kommunizieren.
Und ohne diese Angaben, welche Netzwerkanfragen der Client beantworten können muss kann dir niemand weiterhelfen.
Also nochmal zusammenfassend, damit wir uns auch richtig verstehen:
- jeder soll sein eigenen "Spieler" programmieren
- und damit dann gegen die anderen "Spieler" spielen können, ohne die Möglichkeit des schummelns zu haben ?
Interessant Aufgabe auf jeden Fall
Btw als ehemaliger Programmierer kann ich dir nur nahelegen zu lernen wie man sich kurz und prägnant ausdrückt, das ist fast noch wichtiger als schönen Code zu schreiben
__________________
Lebt wohl war mir eine Freude über viele Jahre mit euch, zumindest mit jenen die mich nicht des trollens bezichtigten...
|
|
|
20.03.13, 18:05
|
#8
|
Erfahrener Newbie
Registriert seit: Mar 2010
Beiträge: 131
Bedankt: 81
|
>die versionen sollen untereinander kompatibel sein, was aber ersteinmal irrelevant ist
>sprich jeder programmiert seinen server anders
>ich hole ein kartendeck raus sage es sei gemischt und verteile die karten
>würdest du mir vertrauen?
da muss man sich dennoch auf schnittstellen einigen... im realen leben zb. vergleichbar mit den mau-mau regeln und der sprache. schonmal probiert dein deck rauszuholen um mit einen japaner am bahnhof zu spielen? )
wenn ein client immer server ist (nicht dediziert!), so ist schummeln leider theoretisch immer möglich - vom mischen mal abgesehen. wie willst du als client gegenchecken, ob dein partner nicht n paar sonderlocken in seinen server implementiert hat -- zeige stapel, tausche karten vom stapel, werfe karten weg ohne rückmeldung?
im realen leben also wie maumau unter blinden...
|
|
|
20.03.13, 18:33
|
#9
|
Banned by himself
Registriert seit: May 2009
Beiträge: 2.938
Bedankt: 2.106
|
Zitat:
[.IMG]C:\Users\Hagemann\Pictures\img009[/IMG]
|
Das ist jetzt nicht dein ernst das du was programmieren möchtest und dann ein Bild mit nem lokalen Pfad hier zu verlinken versuchst
__________________
Lebt wohl war mir eine Freude über viele Jahre mit euch, zumindest mit jenen die mich nicht des trollens bezichtigten...
|
|
|
20.03.13, 18:59
|
#10
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
ok also versuche ich mich mal kürzer und vllt pregnanter aus zu drücken
ersteinmal die aufgabenstellung so wie wir sie bekommen haben (hoffe man kann es sehen/lesen)
http://i46.tinypic.com/iwkcbo.jpg
geeinigt haben wir uns das spiel an sich in java zu programmieren
generell soll die kommunikation über xml von statten gehen (aktion meldung etc)
wie die einzelnen clients mit diesen meldungen umgehen hängt ja dann von den programmierern ab und der "server" überprüft ob ein zug korrekt gemacht wurde oder nicht
Zitat:
Das ist alles andere als irrelevant.
|
irrelevant in bezug auf das mischen
klar spielt das eine rolle für das gesamte
aber die fragestellung bezieht sich (vorerst) "nur" auf das mischen
die einzelnen züge im spiel werden von allen protokolliert und danach wird geguckt ob wer wo geschummelt hat (falls nachweisbar)
|
|
|
20.03.13, 20:06
|
#11
|
Banned by himself
Registriert seit: May 2009
Beiträge: 2.938
Bedankt: 2.106
|
Hmm ok, jetzt wird das ganze schon etwas klarer
Aber meiner Meinung nach ist die Aufgabe überhaupt nicht lösbar.
Es gibt zwei Möglichkeiten das mischen zu behandeln, aber beide eröffnen die Möglichkeit des Betruges:
Wenn ein Client das mischen berechnet kann er da machen was er will, die anderen haben null Möglichkeit zu überprüfen ob das nach einem Zufallsalgorithmus oder geordnet abgelaufen ist.
Die zweite Möglichkeit wäre das sich alle Clients auf denselben Algorithmus einigen. Dann würde zb der Server den anderen nur die Basiszahl mitteilen aufgrund derer alle dasselbe gemischte Deck berechnen können.
Damit hätte aber jeder Client die Information vorliegen wer wann welche Karte abhebt und könnte das komplette Spiel mit offenen Karten spielen. (Was der Server sowieso immer könnte)
Btw ist xml als Kommunikation völlig ungeeignet, da kann jeder mitlesen wer wann welche Karten bekommt.
__________________
Lebt wohl war mir eine Freude über viele Jahre mit euch, zumindest mit jenen die mich nicht des trollens bezichtigten...
|
|
|
21.03.13, 06:49
|
#12
|
Banned
Registriert seit: Aug 2012
Beiträge: 223
Bedankt: 68
|
Zitat:
Zitat von thyriel
Warum willst du den Clients überhaupt mitteilen wie das Deck gemischt wurde ?
lass das am Server. Hebt ein Spieler ab bekommt nur dessen Client die gezogene Karte zugeschickt und fertig.
der Server speichert wer welche Karten hat
|
Im Prinzip richtig. Im Gedanken aber falsch.
Der Client bekommt gar KEINE Karte, er bekommt nur eine Ansicht auf seine Daten.
Die Karten (die Objekt-Instanzen) liegen im Speicher des Servers.
Zitat:
Zitat von thyriel
Das bedeutet das euch die Netzwerkkommunikation vorgegeben werden muss, sonst können die verschiedenen Programme nicht miteinander kommunizieren.
Und ohne diese Angaben, welche Netzwerkanfragen der Client beantworten können muss kann dir niemand weiterhelfen.
|
Dafür gibt es Webservices und Data Contracts.
Hier kommen Standards zum Einsatz. Der Server bietet den "Nächste Karte"-Service an, der Client bedient sich an diesem. Protokoll und Kommunikation muss man dann eben nicht selbst implementieren...
Zitat:
Zitat von thyriel
Btw ist xml als Kommunikation völlig ungeeignet, da kann jeder mitlesen wer wann welche Karten bekommt.
|
... dann ruf mal bitte schnell bei eBay, Amazon, IBM etc. an und erklär diesen dringend, dass deren Webservices alle unsicher sind
XML ist auch hier ein Standard. Zur Verschlüsselung gibt es XML-Encryption.
siehe SOAP oder WS-*
Zitat:
Zitat von thyriel
Hmm ok, jetzt wird das ganze schon etwas klarer
Aber meiner Meinung nach ist die Aufgabe überhaupt nicht lösbar.
Es gibt zwei Möglichkeiten das mischen zu behandeln, aber beide eröffnen die Möglichkeit des Betruges:
Wenn ein Client das mischen berechnet kann er da machen was er will, die anderen haben null Möglichkeit zu überprüfen ob das nach einem Zufallsalgorithmus oder geordnet abgelaufen ist.
Die zweite Möglichkeit wäre das sich alle Clients auf denselben Algorithmus einigen. Dann würde zb der Server den anderen nur die Basiszahl mitteilen aufgrund derer alle dasselbe gemischte Deck berechnen können.
Damit hätte aber jeder Client die Information vorliegen wer wann welche Karte abhebt und könnte das komplette Spiel mit offenen Karten spielen. (Was der Server sowieso immer könnte)
|
Der Server teilt den Clients einen Key vor jedem Spiel mit.
Vielleicht auch nach jedem Zug.
Nach jedem Spiel oder nach jedem Zug einen Wert.
Wert und Key lassen dann die zuletzt gezogene Karte ermitteln.
|
|
|
20.03.13, 21:09
|
#13
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
schon klar dass jeder die xml mitlesen könnte
prinzipiell hatten wir uns das zwecks der kommunikation so gedacht
jeder client muss sich mittels zertifikat am server anmelden
clients dürfen untereinander nicht kommunizieren(falls realisierbar?)
und dann möchte ich eben noch den gedanken der permutation aufgreifen
der server gibt den karten "decknamen" und mischt die karten (permutation ist nichts anderes als mischen)
wie er das gemacht hat wird verschlüsselt und an alle clients weitergegeben (am ende des spiels kann somit überprüft werden ob der server die wahrheit gesagt hat oder nicht)
das gemischte "alias"-deck geht an einen weiteren spieler
der mischt neu, gibt das neue deck an einen weiteren spieler und so weiter, ohne dass andere spieler wissen was wer wie gemischt hat
der letzte spieler gibt das deck zurück an den server und alle anderen clients
problem dabei ist nur die auflösung wenn einer eine karte zieht, da dieser spieler dann automatisch weiß welche karten sich wo im deck befinden oder der server weiß welche karte rausgegeben wird
gibt es sonst noch andere vorschläge wie wir protokolle verschicken können ohne dass jeder genau weiß was drin steht?
wie gesagt es geht mehr um die netzwerksicherheit als um das spiel selbst
|
|
|
20.03.13, 21:35
|
#14
|
Banned by himself
Registriert seit: May 2009
Beiträge: 2.938
Bedankt: 2.106
|
Zitat:
das gemischte "alias"-deck geht an einen weiteren spieler
der mischt neu, gibt das neue deck an einen weiteren spieler und so weiter, ohne dass andere spieler wissen was wer wie gemischt hat
|
Das ändert nicht nur die Spielregeln, es bringt auch null. Das verlagert nur das Problem des absichtlich falsch mischens vom Server zum letzten Spieler.
Zitat:
Zitat von Hagemann
und dann möchte ich eben noch den gedanken der permutation aufgreifen
der server gibt den karten "decknamen" und mischt die karten (permutation ist nichts anderes als mischen)
wie er das gemacht hat wird verschlüsselt und an alle clients weitergegeben (am ende des spiels kann somit überprüft werden ob der server die wahrheit gesagt hat oder nicht)
|
Die Grundidee ist schonmal nicht schlecht
Decknamen usw sind allerdings nicht notwendig.
Wie das ganze doch funktionieren könnte, auch wenn man den mogelnden Server erst am Ende des Spiels entlarven kann:
- Alle müssen denselben Algorithmus zum berechnen des gemischten Decks verwenden
- Am Anfang der Partie sendet der Server die Permutationszahl (also zb die basis die der random() Befehl erzeugt verschlüsselt mit einem symmetrischem Verfahren (zb twofish oder AES), als Keyword wird dabei die Permutationszahl selbst verwendet.
- Am ende der Partie sendet der Server die Permutationszahl nochmals unverschlüsselt.
- Die Clients können dann den den verschlüsselten am Anfang der partie übermittelten Wert überprüfen, das gemischte Deck selbst nachbauen und überprüfen ob auch in der richtigen Reihenfolge abgehoben wurde.
Zitat:
gibt es sonst noch andere vorschläge wie wir protokolle verschicken können ohne dass jeder genau weiß was drin steht?
wie gesagt es geht mehr um die netzwerksicherheit als um das spiel selbst
|
zur generellen Netzwerkkommunikation SSL
die oben genannten synchronen Verschlüsselungen wie Twofish oder AES funktionieren nur wenn beide das "Codewort" kennen, sind also zur generellen Kommunikation nicht geeignet.
__________________
Lebt wohl war mir eine Freude über viele Jahre mit euch, zumindest mit jenen die mich nicht des trollens bezichtigten...
|
|
|
20.03.13, 22:13
|
#15
|
Erfahrener Newbie
Registriert seit: Mar 2010
Beiträge: 131
Bedankt: 81
|
Also ich glaube in die Aufgabe wurde zuviel hinein interpretiert.
"Der Client-Modus verbindet sich zu einem Server..." - Es muss per definition geregelt sein, dass der Server selbst nicht als Client am Spiel teilnimmt und dadurch eine Vertrauensvolle Instanz ist (oder man sich selbst bei Teilnahme als vertrauensvoll ansieht). Der Server kann dann Betrug selbst aufdecken, da er jede Karte von allen Clients kennt. Somit ist auch das Mischen kein Problem; das übernimmt er einfach. Mogeln kann man nur durch Kartelle von Programmierern oder als Serverbereiber. -- Dem Client ist es jedoch überlassen, ob er die nacheinander geworfenen Karten mitzählt.
"Netzwerkprotokoll soll mogeln verhindern"
K.a. ob man da zuviel reininterpretieren sollte... Sieht ja eh dann nur jeder seine Karten, die er vom Server bekommt.
|
|
|
21.03.13, 06:17
|
#16
|
Banned
Registriert seit: Mar 2012
Beiträge: 337
Bedankt: 93
|
Kurze Hinweise:
Hier wird wohl eher gefordert, dass man sich mit Standardproblemen der IT im Kommunikationsbereich auseinandersetzt. D.h. man sollte sich die Best Practices aneignen und anwenden. Wie im Berufsleben gilt auch hier: man darf das viereckige Rad nicht neu erfinden!
- Verschlüsselung: End2End --> Privat & Public Keys oder Point2Point --> SSL
- Protokoll: HTTP
- Kommunikation: REST, SOAP oder OData
- Datenformat: teilw. abh. von d. Komm., XML, JSON
Wenn Du SOAP einsetzt, dann kannst du mit WS- Security alle Punkte auf einmal erschlagen.
Java, C#?
|
|
|
21.03.13, 14:37
|
#17
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Also ersteinmal vielen lieben Dank dass ihr so viele Anregungen gebt
Zitat:
Decknamen usw sind allerdings nicht notwendig.
|
Wirklich? Wir haben uns gedacht dieser Deckname ist wie die Rückseite einer echten Karte, denn da hast du das Bild auch nicht auf beiden Seiten.
Zitat:
- Am Anfang der Partie sendet der Server die Permutationszahl (also zb die basis die der random() Befehl erzeugt verschlüsselt mit einem symmetrischem Verfahren (zb twofish oder AES), als Keyword wird dabei die Permutationszahl selbst verwendet.
- Am ende der Partie sendet der Server die Permutationszahl nochmals unverschlüsselt.
- Die Clients können dann den den verschlüsselten am Anfang der partie übermittelten Wert überprüfen, das gemischte Deck selbst nachbauen und überprüfen ob auch in der richtigen Reihenfolge abgehoben wurde.
|
Diese Idee hatten wir uns auch überlegt , aber eben für das "verdecken" der Karten.
Zitat:
Also ich glaube in die Aufgabe wurde zuviel hinein interpretiert.
|
Leider nicht. Wir sitzen ja mit dem Professor und versuchen ein Lösung zu finden. Keine Angst der Professor hat selber eine Lösung, verrät sie aber selbstverständlich nicht.
Zitat:
Es muss per definition geregelt sein, dass der Server selbst nicht als Client am Spiel teilnimmt und dadurch eine Vertrauensvolle Instanz ist (oder man sich selbst bei Teilnahme als vertrauensvoll ansieht).
|
NOCHEINMAL: Der Server ist und bleibt ein aktiver Mitspieler.
Wir sollen von Anfang an ausschließen, dass wir unseren eigenen Serverpart so programmieren, dass wir wissen welche Karte wir an wen raus geben. Deswegen ja auch das gemeinsame Mischen.
@ProgMaster
Super Antwort! Dankeschön
Auch wenn es nicht mein Problem des Mischens löst.
Zitat:
Protokoll und Kommunikation muss man dann eben nicht selbst implementieren...
|
Ich denke schon dass wir das implementieren müssen. Der Spieler übermittelt seine Aktion über das Protokoll an den Server, welche eine Rundmeldung heraus gibt.
Zitat:
Der Server teilt den Clients einen Key vor jedem Spiel mit.
Vielleicht auch nach jedem Zug.
Nach jedem Spiel oder nach jedem Zug einen Wert.
Wert und Key lassen dann die zuletzt gezogene Karte ermitteln.
|
Somit weiß der Server aber immer noch welche Karte er an wen raus gibt. (Man beachte: Server ist gleichzeitig Spieler)
Selbstverständlich ist es keine einfache Aufgabe, die wir einfach in 2-3 Wochen lösen sollen.
Aber ich hoffe wir können vielleicht doch einen Lösungsweg für das !MISCHEN! im Netzwerk finden.
|
|
|
21.03.13, 22:21
|
#18
|
Erfahrener Newbie
Registriert seit: Mar 2010
Beiträge: 131
Bedankt: 81
|
>NOCHEINMAL: Der Server ist und bleibt ein aktiver Mitspieler.
>Wir sollen von Anfang an ausschließen, dass wir unseren eigenen
> Serverpart so programmieren, dass wir wissen welche Karte wir an wen
>raus geben. Deswegen ja auch das gemeinsame Mischen.
NOCHEINMAL: Irgendwer muss am Ende das Deck "zusammenfügen" - wie im Leben wenn jeder mal kurz mischt (eure Permutation...), der Geber am Ende aber kurz aus dem Raum geht und neu sortiert.
Es kann nicht sichergestellt werden, dass am Ende (der Server) die Mischung einfach durch eine statisch oder dynamisch ermittelt festgelegte "gewinnreihenfolge" austauscht. Hier nützen keinerlei "Zufallszahlzugaben" von Clients.
|
|
|
22.03.13, 05:53
|
#19
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Zitat:
Es kann nicht sichergestellt werden, dass am Ende (der Server) die Mischung einfach durch eine statisch oder dynamisch ermittelt festgelegte "gewinnreihenfolge" austauscht.
|
Ach nein?
Nach dem Spiel kann das durchaus überprüft werden. Wenn jeder Client seine Permutation speichert kann danach überprüft werden ob es verändert wurde. Der Server darf dabei nur nicht die einzelnen Mischvorgänge der Clients mitbekommen.
|
|
|
22.03.13, 06:32
|
#20
|
Banned by himself
Registriert seit: May 2009
Beiträge: 2.938
Bedankt: 2.106
|
Zitat:
Zitat von Hagemann
Ach nein?
Nach dem Spiel kann das durchaus überprüft werden. Wenn jeder Client seine Permutation speichert kann danach überprüft werden ob es verändert wurde. Der Server darf dabei nur nicht die einzelnen Mischvorgänge der Clients mitbekommen.
|
Wie willst du hier eine Manipulation herausfinden ?
Server übergibt A die Permzahl "15"
der "mischt neu" und übergibt an B "22"
der "mischt neu" und übergibt zurück an den Server "7"
Und woher willst du nun wissen ob B die 7 gemischt oder sortiert hat ?
Das ist genauso als alle an nem tisch sitzen, einer mischt heimlich und übergibt die Karten an den nächsten, der letzte der heimlich mischt sortiert sie sich aber... und jetzt überprüf mal ob er gemischt oder sortiert hat.
Und wenn jeder seine eigene Mischmethode programmiert lässt sich am Ende nicht feststellen ob der Server das Deck berechnet hat
Die oben genannte Methode funktioniert schon, und ist im Grunde dasselbe das NetWebs beschrieben hat:
Zitat:
Der Server teilt den Clients einen Key vor jedem Spiel mit.
Vielleicht auch nach jedem Zug.
Nach jedem Spiel oder nach jedem Zug einen Wert.
Wert und Key lassen dann die zuletzt gezogene Karte ermitteln.
|
Zitat:
Zitat von NetWebs
Im Prinzip richtig. Im Gedanken aber falsch.
Der Client bekommt gar KEINE Karte, er bekommt nur eine Ansicht auf seine Daten.
Die Karten (die Objekt-Instanzen) liegen im Speicher des Servers.
|
Hab nie was anderes gesagt...
Zitat:
Dafür gibt es Webservices und Data Contracts.
Hier kommen Standards zum Einsatz. Der Server bietet den "Nächste Karte"-Service an, der Client bedient sich an diesem. Protokoll und Kommunikation muss man dann eben nicht selbst implementieren...
|
Die Verarbeitung der Daten muss aber für alle gemeinsam definiert werden.
Was hilft mir eine Angabe "<id0:7>" wenn ich nicht weis worauf sich das bezieht und was was bedeutet?
Genauso ist es nicht zielführend wenn jeder "Server" seine eigene Art hat Daten bereitzustellen.
__________________
Lebt wohl war mir eine Freude über viele Jahre mit euch, zumindest mit jenen die mich nicht des trollens bezichtigten...
|
|
|
22.03.13, 06:41
|
#21
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Dafür sind doch die Decknamen für die Karten da, bzw. die Rückseiten der Karten. Es werden also die Rückseiten gemischt und nicht die Werte, somit kann doch niemand in dem Sinne sortieren, dass er weiß welcher Wert sich dahinter verbirgt.
Ich weiß es ist eine verzwickte Aufgabe die immer wieder Probleme aufwirft. Deswegen habe ich das Problem auch hier geschildert um möglichst viele Ideen zusammen zu kriegen.
edit:
Was mir noch eingefallen ist.
Wie kann man gemeinsames verschlüsseln realisieren?
Die Idee dahinter:
Die Karten werden alle einzeln verschlüsselt und zwar so, dass für jede Karte jeder Schlüssel benötigt wird um zu wissen welche Karte man gezogen hat. So würde doch eine virtuelle Rückseite entstehen(oder?)
Die Rückseite der Karten werden gemischt, sodass eine beliebige Reihenfolge der Karte entsteht.
|
|
|
22.03.13, 20:34
|
#22
|
Erfahrener Newbie
Registriert seit: Mar 2010
Beiträge: 131
Bedankt: 81
|
[sarkasmus]
hey 1. reihe sitzer. geht mal lieber auf 'ne semester-opening-party statt euch über unwesentliche dinge wie "mischen" den kopf zu zerbrechen.
mit der aufgabe soll euch "verteilte systeme" näher gebracht werden. es soll sicherlich nicht jeder irrsinn wie asymetrische verschlüsselung integriert werden.
ihr werdet sehen, dass (aus erfahrung) die lösung vom prof. zu 90% völlig banane ist. das ist ein theoretiker.
dazu folgende definition von theorie und praxis:
theorie ist, wenn man alles weiß und nichts klappt
praxis ist, wenn alles funktioniert und keiner weiß warum
und ihr versucht theorie und praxis zu vereinigen: am ende funktioniert nichts und keiner weiß warum...
[/sarkasmus]
tut bei der implementation euer bestmögliches um zu entdecken, ob der jemand bescheißt. einhaltung der regeln durch mitzählen des ablegehaufens...: mehr ist nicht groß möglich. auch müsst ihr euch auf schnittstellen (zb. json/xml...) und spielablauf / "rfc" einigen (stinkt bube auf bube? ass auf ass möglich?), sodass programme untereinander kompatibel sind. das ist der 1. schritt innerhalb aller teilnehmer.
hier wird es eh noch genug reibereien geben, da 20 leute = 20 meinungen zur api.
bis nichts besseres gefunden wird, mischt der server. fangt mit der schnittstelle an. ziehe karte, sende abwerfkarte an server (mit return möglich/nichtmöglich), nach abwurf broadcast wer was abgewurfen hat ect. pp.
eh das alles steht ist das halbe semester eh um. - ansonsten steht ihr am ende da und habt mit viel mühe nichts erreicht...
die antwort nützt euch für euer problem nicht, aber vll für's leben
kannst ja am ende mal die lösung vom prof. posten *hehe*
|
|
|
22.03.13, 21:18
|
#23
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Auch wenn der Post als sarkastisch gekennzeichnet wurde, ist er durchaus interessant
Zitat:
es soll sicherlich nicht jeder irrsinn wie asymetrische verschlüsselung integriert werden
|
Du wirst es nicht glauben, aber das soll durchaus gemacht werden.
Wird dürfen eigene Zertifikate schreiben, XML-Schema selber erstellen, eine eigene KI erstellen, Server-Client Kommunikation erstellen und und und. Da ich von solchen Projekten keine Ahnung habe wie sie in Wirklichkeit ablaufen, kann ich nicht beurteilen ob das für uns eine machbare Aufgabe ist oder nicht.
Selbstverständlich beschäftigen wir uns auch nebenbei schon mit der Realisierung des Spiels an sich, dennoch hat der Proffessor dieses Problem mit als erstes mit uns diskutiert.
Zitat:
kannst ja am ende mal die lösung vom prof. posten *hehe*
|
Falls wir eine Lösung gefunden haben sollten, werde ich selbstverständlich erzählen wie diese aussieht.
|
|
|
25.03.13, 12:46
|
#24
|
Erfahrenes Mitglied
Registriert seit: Mar 2010
Beiträge: 672
Bedankt: 653
|
Es ist aber überhaupt nicht nötig, die Karten "herumzureichen". Jeder Client gibt einfach eine Permutation der Karten an den Server und der Server wendet dann die Permutationen der Clients auf das (sortierte) Deck an.
Voila, das Deck ist dann 5x gemischt.
Im Nachinein kann überprüft werden, ob der Server gemogelt hat, indem alle Clients ihre Permutation offen legen.
__________________
my brain has two parts, the right and the left...on the left, there is nothing right...on the right, there is nothing left
|
|
|
25.03.13, 14:16
|
#25
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Prinzipiell hättest du Recht. Wenn das mit dem Server nicht wäre...
Der Server müsste ja dann die Information raus geben welche Karte ein Client gezogen hat und kann sich das ganz einfach merken. Nicht das was wir wollten. Habe über das Wochenende selber mal überlegt ob es überhaupt möglich ist. Bin zu dem Schlus gekommen dass es ohne eine unparteiische Instanz nicht gehen würde...
Oder hat da jemand noch Vorschläge??
|
|
|
25.03.13, 14:49
|
#26
|
Erfahrener Newbie
Registriert seit: Mar 2010
Beiträge: 131
Bedankt: 81
|
Zitat:
Zitat von Hagemann
Bin zu dem Schlus gekommen dass es ohne eine unparteiische Instanz nicht gehen würde...
|
Dito
Der von dir eingegebene Text ist zu kurz. Bitte erweitere den Text auf die minimale Länge von 5 Zeichen.
|
|
|
25.03.13, 20:21
|
#27
|
Erfahrenes Mitglied
Registriert seit: Mar 2010
Beiträge: 672
Bedankt: 653
|
Zitat:
Zitat von Hagemann
Bin zu dem Schlus gekommen dass es ohne eine unparteiische Instanz nicht gehen würde...
|
Der Dealer, der das Deck verwaltet (=Server) hat immer die Möglichkeit, sich die Karten anzusehen und kennt somit auch alle Karten, die die Clients erhalten haben.
Man muss also dafür Sorge tragen, dass keiner der Clients, auch Zugang zu den Informationen des Servers hat (Auch wenn beide auf einem Computer laufen).
Eine andere Möglichkeit wäre nur, die Informationen so dezentral zu verteilen, dass jede Instanz nur eine - für sich genommen - nutzlose Teilmenge der Informationen hat.
So ähnlich soll es ja im TOR Netzwerk funktionieren, wenn ich mich nicht irre.
__________________
my brain has two parts, the right and the left...on the left, there is nothing right...on the right, there is nothing left
|
|
|
26.03.13, 12:39
|
#28
|
Banned by himself
Registriert seit: May 2009
Beiträge: 2.938
Bedankt: 2.106
|
Zitat:
Zitat von HappyMike34
Eine andere Möglichkeit wäre nur, die Informationen so dezentral zu verteilen, dass jede Instanz nur eine - für sich genommen - nutzlose Teilmenge der Informationen hat.
|
Ich glaub nicht dass das mit "kartenmischen" umsetzbar wäre.
Sagen wir mal man splittet die Information der gemischten Karten in Farbe und Wert. Einer wüsste dann zb das als nächstes König kommt, ein anderer das es ein Pik ist.
Mir würd jedenfalls keine Methodik einfallen das mischen dabei dann so umzusetzen das nicht eine völlig ungültige Kombination am Ende rauskommt. (zb 2x Pik König im Deck dafür fehlt Herz)
Egal was man macht, der Server könnte immer mit offenen Karten spielen.
__________________
Lebt wohl war mir eine Freude über viele Jahre mit euch, zumindest mit jenen die mich nicht des trollens bezichtigten...
|
|
|
25.03.13, 15:25
|
#29
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Also der Professor hat uns heute mal gesagt wie es gehen könnte.
Stichwort RSA
Der Client möchte Karte m wissen. Der Server soll aber nicht wissen welches m er entschlüsselt. Also wird es mit einem r verfälscht und der Server entschlüsselt m*r.
Da ich mich mit RSA noch nicht so genau auskenne möchte ich von euch mal wissen ob das eine Variante wäre?
|
|
|
26.03.13, 11:24
|
#30
|
Erfahrener Newbie
Registriert seit: Mar 2010
Beiträge: 131
Bedankt: 81
|
Zitat:
Zitat von Hagemann
Also der Professor hat uns heute mal gesagt wie es gehen könnte.
Stichwort RSA
Der Client möchte Karte m wissen. Der Server soll aber nicht wissen welches m er entschlüsselt. Also wird es mit einem r verfälscht und der Server entschlüsselt m*r.
Da ich mich mit RSA noch nicht so genau auskenne möchte ich von euch mal wissen ob das eine Variante wäre?
|
Per Definition ist ein Server=Client und durch Shared Memory hat dieser auch r. Der Programmierer macht einfach "Public int r"
Auch kann ich dem Prof. nicht ganz folgen wo das "r" herkommen soll und wer zuvor das Deck verschlüsselt haben soll... Ich glaube Verschlüsselung sollte (wenn überhaupt) ontop gesetzt werden. Zuerst sollte (der Prof?) den Vorgang des mischens und der Kartenspeicherung mal näher beschreiben.
>So ähnlich soll es ja im TOR Netzwerk funktionieren, wenn ich mich nicht irre.
Nur das auf Serverseite (zb. mygully.com) und Clientseite (Browser) der Content "klar" ist. Die einzelnen Datenpakete nehmen nur andere Wege.
Wenn du aber auf verteilte Datenhaltung hinaus willst: Das löst nur teils das Schummelproblem und wirft andere Probleme auf.
|
|
|
25.03.13, 16:31
|
#31
|
Banned by himself
Registriert seit: May 2009
Beiträge: 2.938
Bedankt: 2.106
|
[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
Ist eines der oben bereits genannte asynchronen Verschlüsselungssystem, also in etwa die Methode die ich dir genannt hatte
__________________
Lebt wohl war mir eine Freude über viele Jahre mit euch, zumindest mit jenen die mich nicht des trollens bezichtigten...
|
|
|
28.03.13, 07:00
|
#32
|
Erfahrenes Mitglied
Registriert seit: Mar 2010
Beiträge: 672
Bedankt: 653
|
Die Farbe oder der Kartenwert wären keine "nutzlose" Information. Ich habe mir da eher eine Permutation vorgestellt, die erst in der Verbindung mit den Permutationen der anderen Clients den Wert der Karte ergibt.
Aber wahrscheinlich hast du Recht, dass es so ein Verfahren nicht gibt ohne vertrauenswürdige Instanz.
__________________
my brain has two parts, the right and the left...on the left, there is nothing right...on the right, there is nothing left
|
|
|
30.03.13, 09:45
|
#33
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Anscheinend gibt es doch eine Lösung
Ich versuche es mal zu beschreiben.
Der Server mischt die Karten und gibt Ihnen Decknamen. Die gemischten Karten gibt er einen Client weiter. Dieser mischt erneut und gibt sie einem nächsten Client, solange bis alle Clients durch sind. Das zuletzt gemischte Deck geht nur an die Clients und nicht an den Server zurück. Somit kennen die Clients die Reihenfolge der Karten, wissen aber nicht welche Karte sich dahinter versteckt und der Server weiß nicht in welcher Reihenfolge sich die Karten befinden. Zieht ein Client nun eine Karte und nöchte wissen welcher Wert sich dahinter versteckt fragt er den Server mittels RSA Blinding welche Karte er gezogen hat. Möchte der Server eine Karte ziehen kann er einen beliebigen Client fragen welche verdeckte Karte er bekommt und entschlüsselt sie für sich selber.
Klingt kompliziert aber es funktioniert ^^
|
|
|
30.03.13, 16:05
|
#34
|
Erfahrener Newbie
Registriert seit: Mar 2010
Beiträge: 131
Bedankt: 81
|
Zitat:
Zitat von Hagemann
Anscheinend gibt es doch eine Lösung
Ich versuche es mal zu beschreiben.
Der Server mischt die Karten und gibt Ihnen Decknamen. Die gemischten Karten gibt er einen Client weiter. Dieser mischt erneut und gibt sie einem nächsten Client, solange bis alle Clients durch sind. Das zuletzt gemischte Deck geht nur an die Clients und nicht an den Server zurück. Somit kennen die Clients die Reihenfolge der Karten, wissen aber nicht welche Karte sich dahinter versteckt und der Server weiß nicht in welcher Reihenfolge sich die Karten befinden. Zieht ein Client nun eine Karte und nöchte wissen welcher Wert sich dahinter versteckt fragt er den Server mittels RSA Blinding welche Karte er gezogen hat. Möchte der Server eine Karte ziehen kann er einen beliebigen Client fragen welche verdeckte Karte er bekommt und entschlüsselt sie für sich selber.
Klingt kompliziert aber es funktioniert ^^
|
Es ändert nichts an der Problematik: Ein Server=Client laut eurer Problemstellung. Somit liegen dort bei diesem Spieler am Ende beide Informationen (ich sagte ja schon "Shared Memory")! Und wenn dieser Client/Server auch noch als letztes mischt könnte man sich die Mischrunde gleich sparen.
Auch handelt ihr euch dadurch weitere Probleme/Overhead. Was ist, wenn ihr einen "stinker" dabei habt, der "aus spaß" einfach Karten entfernt und Decknamen mehrfach einmischt, nur um das Spiel zu bashen... Wer übernimmt die Fehlerkontolle etc? Auch verstehe ich den Ablauf nicht, wann wer wo welche Karte anfordert? Wer stellt sicher, dass der Server nur die Entschlüsselung der richtigen Karte (zähler) an den richtigen Client genehmigt (das setzt ebenfalls einen sauber implementierten Server voraus)? Mir fallen auch gleich noch zig andere Fragen/Probleme ein...
Auch bräuchte man dafür kein RSA, sondern ein Server müsste nur eine Tabelle führen.
zufalls-id, karte
|
|
|
31.03.13, 08:23
|
#35
|
Anfänger
Registriert seit: Jul 2009
Beiträge: 21
Bedankt: 1
|
Die Problematik wird dadurch gelöst dass der Server/Client eben nur am Anfang mischt und die Endkonstellation nicht kennt. Der Server-Client muss eben wenn er eine Karte zieht einen anderen Client fragen welche verdeckte Karte er bekommt und kann diese selbst entschlüsseln.
Die Fehlerkontrolle kann erst am Ende eines Spiels statt finden, indem jeder Client seinen Mischvorgang mit einem TimeStamp verschlüsselt und am Ende aufdeckt.
Zitat:
Auch verstehe ich den Ablauf nicht, wann wer wo welche Karte anfordert?
|
Prinzipiell ist es doch wie im richtigen Spiel. Jeder Client bis auf den Server Client kennt die Reihenfolge der verdeckten Karten und weiß welche er ziehen muss.
Zitat:
Wer stellt sicher, dass der Server nur die Entschlüsselung der richtigen Karte (zähler) an den richtigen Client genehmigt (das setzt ebenfalls einen sauber implementierten Server voraus)?
|
Selbstverständlich muss der Server korrekt implementiert sein. Das ist ja schonmal eine Grundvorraussetzung. Und nur der Spieler, der Einen Kartenwert anfordert, weiß auch wie diese "geblindet" wurde, womit die Entschlüsselung nur für Ihn einen Sinn ergibt.
|
|
|
Forumregeln
|
Du kannst keine neue Themen eröffnen
Du kannst keine Antworten verfassen
Du kannst keine Anhänge posten
Du kannst nicht deine Beiträge editieren
HTML-Code ist Aus.
|
|
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:13 Uhr.
().
|