Verschlüsselung mit mehreren Passwörtern
lima-city → Forum → Programmiersprachen → C/C++ und D
bearbeiten
beispiel
benutzer
datei
datum
frage
inhalt
liegen
login
mache
nutzen
nutzer
programm
sinn
stellen
system
verteilen
verwaltung
vier
zugreifen
-
Hallo,
ich schreibe grade ein Programm und ich weiß, dass die Frage eigentlich nicht hierher gehört, aber eigentlich auch sonst nirgendwo rein. Aber da ich in C++ schreibe am ehesten noch hierher:
Gibt es eine Verschlüsselung, bei der man mehrere Passwörter nutzen kann?
Also im Prinzip so: 3 Nutzer, A,B und C.
Eine Datei, die verschlüsselt ist. A, B und C sollen aber jeweils unterschiedliche Passwörter haben und dennoch an den (unverschlüsselten) Inhalt der Datei herankommen. Dennoch muss die Datei verschlüsselt sein. Gibt es sowas? Wenn ja, wie kann man das in C++ umsetzen?
Gruß Tillorgias -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Also für den Fall, dass es sowas nicht gibt (Ich könnte mir nicht vorstellen, wie sowas funktionieren soll...) könnte ich mir ein Workaround vorstellen: Einfach einen Schlüssel verschlüsseln ;)
Um das zu verdeutlichen:
* Daten werden mit einem Schlüssel verschlüsselt.
* Dieser Schlüssel wird für die jeweiligen Benutzer gespeichert.
* Der gespeicherte Schlüssel wird mit den Benutzerpasswörtern verschlüsselt.
Und schon können alle Benutzer auf die verschlüsselten Daten zugreifen :)
Nur so als Idee. -
Die einzigste Idee, die mir momentan in den Sinn kommt ist leider sehr Speicherplatzintensiev, und sieht so aus: Mache die Datei 3 mal, jedes mal einen anderen Schlüssel, mache es optional (also dass alle 3 geprüft werden, ob der Schlüsel korrekt ist), und dann packe alles zusammen in eine Datei.
mfg drafed-map -
Hey, Danke nerdinator...
Das hat gereicht:
bei mir sieht die Datei jetzt so aus:
3 Stellen: Anzahl der Nutzer, danach
4 Stellen: Länge des Universalschlüssels
Die Passwörter (Länge = anzahl nutzer * länge universalschlüssel)
Text
MD5 (Zur kontrolle)
Gibt es sowas bereits?
@drafed-map
Das ist leider nicht möglich:
Wenn A die Datei ändert, hat B noch nicht die geänderte Version. -
tillorgias schrieb:
@drafed-map
Das ist leider nicht möglich:
Wenn A die Datei ändert, hat B noch nicht die geänderte Version.
Achso, das ist logisch. Ich dachte, du brauchst das, um Daten auf sicherem Weg zu übergeben, dass jeder der 3 User die Datei auch ändern soll habe ich nicht gewusst. -
tillorgias schrieb: Hey, Danke nerdinator...
Soweit ich weiss gibt es festplatten-verschlüsselungssysteme, welche schon einen "Multi-User-Support" anbieten. Truecrypt hatte sowas (nach meinem wissensstand) bisher zumindest noch nicht, aber sie arbeiten wohl dran. (Hab mich länger nicht mehr damit beschäftigt... Kann sein, dass die das schon umgesetzt haben)
Das hat gereicht:
bei mir sieht die Datei jetzt so aus:
3 Stellen: Anzahl der Nutzer, danach
4 Stellen: Länge des Universalschlüssels
Die Passwörter (Länge = anzahl nutzer * länge universalschlüssel)
Text
MD5 (Zur kontrolle)
Gibt es sowas bereits?
Wenn ich das richtig sehe, speicherst du also alles in einer Datei? Ich bin mir grad nicht sicher, in wiefern das ein Sicherheitsrisiko darstellt. Aber was besseres fällt mir so auf die schnelle glaube ich grad auch nicht ein. Des weiteren ist mir nicht bewusst, in wiefern du das mit den "Stellen" meinst. Ich denke, man kann davon ausgehen, dass an so ziemlich keinem System 16.581.375 Benutzer arbeiten, also würde ich für die Benutzeranzahl maximal 16 Bit (2 Byte, also 2 Zeichen - entspricht 65.025 möglichen Benutzern ) reservieren. die länge des Universalschlüssels sollte die 255 stellen nicht überschreiten, also reichen da bereits 8 Bit (1 Byte also 1 Zeichen). Ist allerdings natürlich ansichtssache.
Beitrag zuletzt geändert: 28.7.2009 16:54:10 von nerdinator -
Hallo,
ja, es soll ja auch nicht i-welche bankdaten oder so verschlüsseln - die sache mit der reservierung mache ich auch noch anders, aber momentan habe ich so schon meine probleme mit dem code...
Ich habe mir vor 3 tagen die neueste version von truecrypt heruntergeladen - da gibt es das glaube ich noch nicht (oder ich habe es nicht gefunden).
Ich danke dir trotzdem. Ich denke der Thread kann dann geschlossen werden, wenn nicht noch jemand einen total kreativen vorschlag auf lager hat. -
Wuhu, endlich mal ein Kryptothema. Darüber hab ich sowohl Studien- wie auch Diplomarbeit geschrieben. *freu*
Der Ansatz den Nerdinator vorgeschlagen hat ist der sinnigste und auch derjenige, der tatsächlich in verteilten Kryptosystemen Anwendung findet.
Anstelle allerdings den Schlüssel für die Datei händisch an die Personen zu verteilen, kann man das ganze einem Schlüsselverwaltungssystem aufs Auge drücken.
Diese Verwaltung, kennt alle geschützten Objekte, deren Schlüssel, sowie die Nutzer. Weiterhin weiß es, auf welche Objekte welcher Nutzer zugreifen darf. Wenn sich nun ein Nutzer gegenüber der Verwaltung authentisiert hat und authorisiert wurde, darf sich der Nutzer eben diesen Schlüssel für das besagte Objekt abholen. Der Vorteil ist, dass Schlüsselwechsel viel unkomplizierter vonstatten gehen. Die ganze Chose mit der Verwaltung und dem Schlüssel hin und herschieben, kannst du ja transparent implementieren, so dass der Nutzer nichts davon mitbekommt.
Jedwege Frage zu Kryptalgorithmen oder -verfahren, kannst mir gerne eine PM schicken. Ich bin in der Thematik recht fit.
cu -
census schrieb:
Darüber habe ich ebenfalls bereits nachgedacht, was den Daten allerdings eine ganze Menge an Flexibilität nimmt. So kannst du nur noch auf die Daten zugreifen, wenn sie sich auf dem System befinden. Ich schätze, das war nicht beabsichtigt.
Wuhu, endlich mal ein Kryptothema. Darüber hab ich sowohl Studien- wie auch Diplomarbeit geschrieben. *freu*
Der Ansatz den Nerdinator vorgeschlagen hat ist der sinnigste und auch derjenige, der tatsächlich in verteilten Kryptosystemen Anwendung findet.
Anstelle allerdings den Schlüssel für die Datei händisch an die Personen zu verteilen, kann man das ganze einem Schlüsselverwaltungssystem aufs Auge drücken.
Diese Verwaltung, kennt alle geschützten Objekte, deren Schlüssel, sowie die Nutzer. Weiterhin weiß es, auf welche Objekte welcher Nutzer zugreifen darf. Wenn sich nun ein Nutzer gegenüber der Verwaltung authentisiert hat und authorisiert wurde, darf sich der Nutzer eben diesen Schlüssel für das besagte Objekt abholen. Der Vorteil ist, dass Schlüsselwechsel viel unkomplizierter vonstatten gehen. Die ganze Chose mit der Verwaltung und dem Schlüssel hin und herschieben, kannst du ja transparent implementieren, so dass der Nutzer nichts davon mitbekommt.
Wenn ich nun also eine Datei beispielsweise zu einem Projekt-Partner schicke, kann dieser die Daten, wenn er in einem anderen "System" arbeitet nicht mehr entschlüsseln.
Prinzipiell gebe ich dir aber recht: Wenn man das ganze über eine "Schlüsselverwaltung" macht, ist das alles wesentlich einfacher, wahrscheinlich sicherer und weniger umfangreich zu gestalten. -
Also ich weis von der Uni...
Mache die Datei 3 mal, jedes mal einen anderen Schlüssel, optional alle 3 müssen geprft. werden, un puffe aleess in eine Data!
Gruß -
fabipht schrieb:
Erstmal: Die Rechtschreibung ist ja grausam :(
Also ich weis von der Uni...
Mache die Datei 3 mal, jedes mal einen anderen Schlüssel, optional alle 3 müssen geprft. werden, un puffe aleess in eine Data!
Gruß
Des weiteren birgt das ganze ein Problem in sich: Wenn ein Benutzer die Datei verändert, verändert sie sich nicht in den Dateien der anderen Benutzer. Mag ja sein, dass das nicht beabsichtigt ist, aber dann fällt das in die Kategorie "Verschlüsselung von mehreren Dateien mit mehreren Passwörtern" - nicht in die Kategorie "Eine Datei mir mehreren Passwörtern verschlüsseln".
Wenn man census glauben schenken darf, ist die von mir auf die schnelle erdachte Art wohl die einzige Art, das Sinnvoll zu nutzen - wobei die Frage bestehen bleibt, ob die Datei auf einem, oder auf mehreren Systemen benutzt werden soll. Je nachdem ist eine Schlüsselverwaltung angebracht oder unsinnig. -
Also, ich danke erstmal für die antworten.
Aber das mit der Schlüsselverwaltung habe ich noch nicht ganz begriffen.
Wie genau soll das funktionieren?
Es wäre schön, wenn ihr mir das nochmal erklärt. Ich habe zum beispiel nicht verstanden, warum das nicht auf unterschiedlichen Systemen funktioniert. Freue mich auf eure antworten (wir scheinen ja Experten in der Runde zu haben!)
Gruß, Tillorgias -
Ich weiß nicht, wie die anderen das mit der Schlüsselverwaltung meinen, aber ich kann mir vorstellen, dass es einfach so aussieht, dass es genau einen Schlüssel gibt und diesen Schlüssel kennt nur das Programm selber.
Die Benutzer haben im eigentlichen Sinne keine Schlüssel, sondern nur Passwörter und das Programm ver- und entschlüsselt den Text nur, wenn man ihm eine von vielen richtigen Nutzer+Passwort-Kombinationen liefert. -
Es mag an der Stelle hilfreich sein sich mal in die Dokumentation von Luks einzulesen, bzw die Prinzipien die dem zugrund liegen, da cryptsetup Luks ja im Prinzip eben etwas derartiges umsetzt - ein Verschlüsselter Container mit verschiedenen Passwörtern/Schlüsseln.
Die Quellen von Luks sollten ja frei verfügbar sein. -
bladehunter schrieb:
Ich weiß nicht, wie die anderen das mit der Schlüsselverwaltung meinen, aber ich kann mir vorstellen, dass es einfach so aussieht, dass es genau einen Schlüssel gibt und diesen Schlüssel kennt nur das Programm selber.
Die Benutzer haben im eigentlichen Sinne keine Schlüssel, sondern nur Passwörter und das Programm ver- und entschlüsselt den Text nur, wenn man ihm eine von vielen richtigen Nutzer+Passwort-Kombinationen liefert.
Dabei musst du aber die Sicherheit sehn. Dann könnte man ja das Programm verändern, damit es alle Passwörter aktzeptiert. Siehe CrackMe. -
Darum verschlüsselt man ja den Schlüssel:
Die Datei sieht wie folgt aus:
Schlüssel X verschlüsselt mit Schlüssel A.
Schlüssel X verschlüsselt mit Schlüssel B.
Schlüssel X verschlüsselt mit Schlüssel C.
Schlüssel X verschlüsselt mit Schlüssel D.
Eigentlicher Inhalt verschlüssel mit Schlüssel X.
Wobei die Schlüssel wie folgt gebaut sind:
Schlüssel X: einmal willkürlich vom Verfasser festgelegt.
Schlüssel A: gesät aus Login A und Passwort A.
Schlüssel B: gesät aus Login B und Passwort B.
Schlüssel C: gesät aus Login C und Passwort C.
Schlüssel D: gesät aus Login D und Passwort D.
Nun nützt dir auch eine Änderung der Software nichts ohne Kenntnis eines Login/Passwort-Pärchens.
Beitrag zuletzt geändert: 7.8.2009 8:59:53 von census -
Ich frage mich nur wozu das nützen soll?
Warum gibt man nicht gleich allen den Schlüssel X? -
reimann schrieb: Ich frage mich nur wozu das nützen soll?
Warum gibt man nicht gleich allen den Schlüssel X?
Zuerst dürfen A, B, C und D die Datei bearbeiten und haben folglich Schlüssel.
Dann ändert sich die Policy und C darf nicht mehr darauf zugreifen. Man löscht einfach seinen Eintrag aus der Datei und der Fisch ist geschuppt.
Würde man direkt den Schlüssel X an alle vier verteilen, müsst man nun einen neuen Schlüssel Y generieren, die Datei neu verschlüsseln und dann Y an A, B und D verteilen. Klassisches Schlüsselverteilungsproblem von symmetrischen Verfahren.
Außerdem kann auf diese Weise, der Nutzer A mit EINEM Passwort die Dateie G, K, L und M bearbeiten, weil er dort Einträge hat, obwohl jede Datei anders verschlüsselt ist und eine andere Nutzerliste hat. -
census schrieb:
Zuerst dürfen A, B, C und D die Datei bearbeiten und haben folglich Schlüssel.
Dann ändert sich die Policy und C darf nicht mehr darauf zugreifen. Man löscht einfach seinen Eintrag aus der Datei und der Fisch ist geschuppt.
Würde man direkt den Schlüssel X an alle vier verteilen, müsst man nun einen neuen Schlüssel Y generieren, die Datei neu verschlüsseln und dann Y an A, B und D verteilen. Klassisches Schlüsselverteilungsproblem von symmetrischen Verfahren.
Außerdem kann auf diese Weise, der Nutzer A mit EINEM Passwort die Dateie G, K, L und M bearbeiten, weil er dort Einträge hat, obwohl jede Datei anders verschlüsselt ist und eine andere Nutzerliste hat.
Allerdings muss es sowieso jedesmal wenn es verändert wird neu verschlüsselt werden, oder wie stellt ihr euch das vor?
Jeder der es bearbeiten will braucht also zwangsläufig den X-Schlüssel. Außerdem ist das mit dem Passwort zwar verschlüsselt, aber man kommt doch sicher dann auch an den unverschlüsselten Schlüssel ran, weil er ja zum entschlüsseln der Datei auch im plain vorhanden sein muss. -
reimann schrieb:
Allerdings muss es sowieso jedesmal wenn es verändert wird neu verschlüsselt werden, oder wie stellt ihr euch das vor?
Jeder der es bearbeiten will braucht also zwangsläufig den X-Schlüssel. Außerdem ist das mit dem Passwort zwar verschlüsselt, aber man kommt doch sicher dann auch an den unverschlüsselten Schlüssel ran, weil er ja zum entschlüsseln der Datei auch im plain vorhanden sein muss.
Selbstverständlich wird die Datei verschlüsselt, nachdem sie verändert wurde. Alles andere wäre ja leicht sinnlos.
Wieso soll Schlüssel X als Plaintext vorliegen? In meinem beispiel tut er das nicht . . . -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
