Archiv verlassen und diese Seite im Standarddesign anzeigen : e-Brief-Verschlüsselung: Ein Schlüssel für alle?
Thanatos
2009-04-24, 16:23:38
Grüßt euch,
mich würde interessieren ob es mit OpenPGP möglich ist einen Schlüssel für eine ganze Gruppe von personen zu verwenden, also eine art vertrauliches Rundschreiben.
Würde dies grundsätzlich funktionieren, wenn ja, bestünde hierdurch ein erhöhtes Sicherheitsrisiko (abgesehen davon, dass die Wahrscheinlichkeit mit jeder eingeschlossenen Person steigt, dass das Passwort in Umlauf gerät)?
Vielen Dank im Voraus!
Grüßt euch,
mich würde interessieren ob es mit OpenPGP möglich ist einen Schlüssel für eine ganze Gruppe von personen zu verwenden, also eine art vertrauliches Rundschreiben.
Vielen Dank im Voraus!
Ja, geht.
Würde dies grundsätzlich funktionieren, wenn ja, bestünde hierdurch ein erhöhtes Sicherheitsrisiko (abgesehen davon, dass die Wahrscheinlichkeit mit jeder eingeschlossenen Person steigt, dass das Passwort in Umlauf gerät)?
Ja, ist so.
Thanatos
2009-04-24, 18:35:25
Und wodurch besteht dieses Sicherheitsrisiko im spezielle, wenn man fragen darf?
Mir würde nur einfallen, dass der eigene Schlüssel und das Passwort natürlich gleich Schlüssel des anderen sind, was natürlich verständlich ist.
Du müsstest einen Private Key an den Personenkreis verteilen der die Nachrichten erhalten soll. Und jeder von denen darf ihn natürlich nicht aus Versehen irgendwie veröffentlichen. Das ist das Sicherheitsrisiko.
Ein Passwort gibt es bei PGP nicht. Du erstellst einen Private Key und verteilst dann den dazu gehörenden Public Key. Mit dem Public Key kann man Nachrichten für dich verschlüsseln und nur du kannst sie dann mit deinem geheimen Private Key entschlüsseln (deshalb asymmetrische Kryptographie).
The_Invisible
2009-04-24, 19:03:37
so oder so müssten sie zumindest mal einen schlüssel importieren.
dann lieber gleich jeder nen eigenen private key erstellen und dir den public geben.
mfg
Thanatos
2009-04-24, 19:07:03
Du müsstest einen Private Key an den Personenkreis verteilen der die Nachrichten erhalten soll. Und jeder von denen darf ihn natürlich nicht aus Versehen irgendwie veröffentlichen.
Das ist das Sicherheitsrisiko.
Ach so, ja, das war ja auch dieses Sicherheitsrisiko, welches ich schon selbst in meinem Eingangsbeitrag ausgeschlossen, da ich mir dem bereits bewusst bin, es aber als kein größeres Problem erachte, da eigentlich alle Personen vertrauenswürdig sind und die Gruppe sich auch persönlich kennt.
Soweit ich das mitbekommen habe, ist es ja auch möglich die nachricht mit mehreren Schlüsseln zu versehen, damit dann jeder die nachricht mit seinem eigenen privaten Schlüssel diese wieder entschlüsseln kann. Dies erscheint zwar sicherer, jedoch müssten dann alle einen Schlüssel erstellen, was manchen dann schon Probleme bereiten würde (erhöht den Unterstützungsaufwand ungemein) und sicherlich viele zu sehr einfachen Passwörtern tendieren würden - nach einer aktuellen Studie ist ja 12345, dichtgefolgt vom Geburtstag, das beliebteste Passwort. So etwas wäre der Sicherheit dann wohl absolut nicht zuträglich, da der schwächste Schlüsesel dann auch das schwächste Glied in der Kette wäre, da es Rundbriefe, natürlich mit gleichem Inhalt, sind welche dann natürlich komplett bekannt sind.
Nach dieser Überlegung müsste es daher eigentlich egal sein, wie herum man das Pferd aufzäumt. :uponder:
so oder so müssten sie zumindest mal einen schlüssel importieren.
dann lieber gleich jeder nen eigenen private key erstellen und dir den public geben.
mfg
Aber, um noch einmal auf meinen oberen Gedankengang zurückzukommen, erhöht dies wirklich die Sicherheit? Denn jede nicht willkommene außenstehende Person, welchen einen privaten Schlüssel von einer Person der geschlossenen Gruppe kennt, kennt ja somit dennoch den Briefverkehr aller, da der Inhalt der Nachrichten, der an alle geschickt wird, identisch ist.
Da ich jedoch auch den privaten Schlüssel festlegen würde, hätte es zumindest den Vorteil, dass das Passwort in seiner Ausführung sehr sicher durch großzügige Verwendung von Sonderzeichen, Zahlen und Buchstaben ohne logisches Muster wäre.
Unterliege ich hierbei einem Denkfehler, so berichtigt mich bitte.
The Cell
2009-04-24, 19:30:34
Der Punkt ist der Aufwand bei der Schlüsselverteilung.
Wenn bei immer wieder verwendetem Private Key, einmal dieser nach außen komment, inkl. Passphrase, dann musst du bei ALLEN Teilnehmern die Schlüssel austauschen.
Bei unterschiedlichen priv. Schlüsseln lediglich den des Empfängers und damit korrespondierend den pub. Key.
Gruß,
TC
(del)
2009-05-09, 16:33:22
@Thanatos
Letztendlich erscheint mir die Lösung bei der jeder seinen eigenen Key hat und man an mehrere Personen verschlüsselt vom Aufwand her wesentlich simpler.
Bist du auch der Meinung, daß wenn du eine Hammer Passpharase wählst, die Leute sicher mit ihr umgehen, falls du sie dazu überredest sie zu benutzen? Ich schätze die wird irgendwo in einer Passwort.txt landen und wird per Copy&Paste eingefügt.
Das sagen meine Erfahrungswerte :uup: Lieber also bissl mehr Aufklärungsarbeit leisten, den Leuten KeePass 1.x portable beibringen und mit "jeder hat seinen eigenen Key" weitermachen.
Das Erzeugen der Keys mit Thunderbird und Enigmail, wie auch ihre Verwaltung, ist wie Fahrradfahren lernen. Kann man nicht dahin, dann muß man nur 1x eine Viertelstunde am Telefon dadurch ;)
Merke: Psychologie und Menschenkenntnis machen beim Erdenken von brauchbaren Sicherheitslösungen 60% aus.
Ich denke The Cell würde mir sogar bei 80% nicht widersprechen. Wir wollen aber nicht übertreiben ;)
Soweit ich das mitbekommen habe, ist es ja auch möglich die nachricht mit mehreren Schlüsseln zu versehen, damit dann jeder die nachricht mit seinem eigenen privaten Schlüssel diese wieder entschlüsseln kann.
Ja und das ist auch die normale richtige Vorgehensweise bei PGP.
Aber das was du machen willst, dafür brauchst du kein PGP, bzw. ist PGP der falsche Ansatz, da viel zu umständlich.
Wenn du an x Leute geheime Daten schicken möchtest, dann packst du diese Daten einfach mit 7zip und nutzt die in 7zip eingebaute AES Verschlüsselungsfunktion um die Daten zu verschlüsseln.
Und dann schickst du den Leuten einfach die *.7z Datei via eMail oder ladest sie auf rapidshare hoch und schickst nur den RS Link via e-Mail.
Letztere Variante hat den Vorteil, daß die Leute sich aussuchen können, wann sie große Dateien aus dem Internet saugen sollen.
Denn große Dateien per e-Mail zu schicken, das mag nicht jeder.
Alternativ zu 7zip kannst du natürlich auch einen Truecrypt Container verschicken.
Am Schluß mußt du nur dafür sorgen, daß alle Teilnehmer 7zip oder Truecrypt haben und das Passwort von dir erhalten.
HeldImZelt
2009-05-10, 01:00:03
Das kommt auf den Anwendungsfall an. Wenn man die Funktionen einer Emailanwendung bevorzugt (Organisation, Suchfunktion, usw.), ist das schon ratsam.
Normalerweise wird jede Nachricht mit jedem public key individuell verschlüsselt. Man kann nicht eine Nachricht mit einem public key für verschiedene Empfänger mit verschiedenen Schlüsseln (private key) erzeugen.
Aber das was du machen willst, dafür brauchst du kein PGP, bzw. ist PGP der falsche Ansatz, da viel zu umständlich.
...
Alternativ zu 7zip kannst du natürlich auch einen Truecrypt Container verschicken.
...
Am Schluß mußt du nur dafür sorgen, daß alle Teilnehmer 7zip oder Truecrypt haben und das Passwort von dir erhalten.Falls es um "Windowsumfeld" geht bietet sich für sowas eher AxCrypt. Das ist nicht mindervertrauenswürdig wie 7-zip. Und hat den Vorteil, daß es eine Art SFX backen kann. Die Leute brauchen also garnichts installieren. Sie müßen nur diese Winexe starten können.
Falls es sich nicht um sehr gelegentlichen Versand von größeren Datenmengen handelt ist PGP on Thunderbrid/Enigmail klar die EINFACHERE und wenig läsitge Lösung.
Um welche Datenmengen es sich handelt hat Thanatos imho auch garnicht erwähnt.
Falls es um "Windowsumfeld" geht bietet sich für sowas eher AxCrypt. Das ist nicht mindervertrauenswürdig wie 7-zip. Und hat den Vorteil, daß es eine Art SFX backen kann. Die Leute brauchen also garnichts installieren. Sie müßen nur diese Winexe starten können.
Und dann ist sicher einer dabei der nen Mac hat.
SFX ist immer Müll, so etwas habe ich früher mal benutzt als ich von Computern noch keine Ahnung hatte und dacht da wäre gut, aber heute würde ich das nie wieder einsetzen. Schon gar nicht zum archivieren.
Alle SFX Dateien die ich angelegt hatte, habe ich inzwischen wieder entpackt und neu gepackt.
Ich selbst habe damals zu DOS Zeiten dafür ARJ verwendet.
Aber egal, die SFX Dinger waren dennoch Müll.
Und 7z kann, wenn ich mich richtig erinnere, ebenfalls solche selbstextrahierende Dateien anlegen.
HeldImZelt
2009-05-10, 04:02:27
Die meisten Packer (bei Winrar bin ich mir sicher) können aber auch SFX Archive (zumindest die Eigenen) erkennen und öffnen, unabhängig vom SFX Modul.
Die meisten Packer (bei Winrar bin ich mir sicher) können aber auch SFX Archive (zumindest die Eigenen) erkennen und öffnen, unabhängig vom SFX Modul.
Zu DOS Zeiten ging da nicht.
Thanatos
2009-05-10, 09:01:03
Um welche Datenmengen es sich handelt hat Thanatos imho auch garnicht erwähnt.
Ich dachte, wenn ich nichts Weiteres explizit erwähne, dass hieraus klar wird, dass es sich um ganz einfache e-Briefkorrespondenz handelt.
Es werden einfach Rundbriefe mit Text und ab und an einem Anhang sein, welche aber wohl nie größer als 2mb sein werden.
Sollte eigentlich unkritisch sein.
Der Schwerpunkt liegt hierbei wirklich auf dem Inhalt der Nachrichten selbst.
darph
2009-05-10, 12:58:24
Wenn ich Abschnitt 2.7.3 in der RFC zu S/MIME richtig interpretiere, sollte der Mailclient verstehen, wenn man eine Email verschlüsselt an mehrere Empfänger verschickt und automatisch die Email an jeden Empfänger einzeln verschicken.
Das ist multiplattform, da fast jeder Client S/MIME versteht. Das ist User-Friendly, da man lediglich einmal ein Zertifikat importieren muß. Man muß nichts extra installieren. Und es ist bequem, da es für den Autor (zumindest nach der RFC) aussieht, als verschicke er die Email nur einmal.
Besorg mit den Leuten ein Zertifikat von Thawte (kostet nyx), CaCert (etwas unbequemer, aber dafür kein Unternehmen) oder stelle mit OpenSSL selbst welche aus.
Die Leute importieren ihr Zertifikat in den Schlüsselbund des OS' und schicken dir eine signierte Email. Du schickst ihnen eine ebensolche und künftig könnt ihr alle eure Kommunikation verschlüsseln.
(del)
2009-05-10, 13:57:44
Ich dachte, wenn ich nichts Weiteres explizit erwähne, dass hieraus klar wird, dass es sich um ganz einfache e-Briefkorrepondenz handelt.
Es werden einfach Rundbriefe mit Text und ab und an einem Anhang sein, welche aber wohl nie größer als 2mb sein werden.
Sollte eigentlich unkritisch sein.
Der Schwerpunkt liegt hierbei wirklich auf dem Inhalt der Nachrichten selbst.Wenn du GELEGENTLICH Rundbriefe verschickst und alle einen WinPC haben, nimm AxCrypt und erzeuge SFX damit ("Kopie als EXE verschlüsseln").
Laß dich nicht direkt auf S/MIME ein. IMHO =) mögen darph oder nggalai S/MIME, weil Apple dem Programmierer von GPGMail dauernd Steine in den Weg legt. Da kommt keine vernünftige Lösung bei raus und man beschäftigt sich damit nicht weiter, weil es nicht ganz rund läuft. Das ist verständlich, falls man Thunderbird2 nicht nutzt.
Es sei denn deine OSX-Leute benutzen Thunderbrid2. Dann sollte auch Enigmail brauchbar sein. Da ist es ebenfalls so, daß du die Rundmail nur EINMAL verschickst.
Den von darph erwähnten Vorteil verstehe ich nicht. Das Handling ist mit AxCrypt, 7-zip, OpenPGP oder S/MIME gleich. Man verschickt eine Rundmail, also tut es nur EINMAL.
Wenn du erstmal Thawte oder CaCert besuchst oder selbst für alle deine Briefpartner mit OpenSSL Zertifikate erstellst (sie werden es wohl kaum alleine können, schätz ich mal), dann wirst du "User-Friendly" garantiert neu definieren =)
Es wird sich wohl kaum um geschäftliche Korespondenz handeln, also halt dich von S/MIME erstmal fern.
Zu S/MIME ist schon viel geschrieben worden. Ich meine darph hat das damals unkommentiert gelassen. Sowieso ist diese Diskussion noch nicht wirklich alt.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5394156#post5394156
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6971561#post6971561
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.