Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › PGP: Hochsicher, kaum genutzt…

PGP hat ZU viele Probleme

  1. Thema

Neues Thema Ansicht wechseln


  1. PGP hat ZU viele Probleme

    Autor: Port80 24.06.15 - 12:41

    PGP hat folgende Probleme, die es nicht haben dürfte

    1. Man muss den Schlüssel selbst auf einem Schlüsselserver hinterlegen - besser wäre es, direkt beim Mailanbieter den pubKey hinterlegen zu lassen. (X@y.com schickt an q@c.com eine Mail, bei c.com wird nach dem pubKey gefragt und verschlüsselt)

    2. Der private Schlüssel muss irgendwo aufbewahrt werden : Am besten optional beim Mailanbieter, jedoch per AES mit einem eigenen Passwort verschlüsselt (123456 kann man sich besser merken als ein 4096bit großer Schlüssel)

    3. Henne-Ei-Problem : Kaum ein Maildienst hat das nativ implementiert -> kaum einer nutzt das -> Niemand implementiert ...

    4. Es ist nicht cool. Das Argument der Masse. Mit einem neuen Namen, modernem Logo und weniger Technikgelaber sollte das jeder akzeptieren können. Niemand interessiert es, welcher Algorithmus genutzt wird, das verwirrt nur. Es muss aber klar sein, dass es einfach, sicher und für jeden verständlich ist.

  2. Re: PGP hat ZU viele Probleme

    Autor: AllAgainstAds 24.06.15 - 12:44

    Port80 schrieb:
    --------------------------------------------------------------------------------
    > PGP hat folgende Probleme, die es nicht haben dürfte
    >
    > 1. Man muss den Schlüssel selbst auf einem Schlüsselserver hinterlegen -
    > besser wäre es, direkt beim Mailanbieter den pubKey hinterlegen zu lassen.
    > (X@y.com schickt an q@c.com eine Mail, bei c.com wird nach dem pubKey
    > gefragt und verschlüsselt)
    >
    > 2. Der private Schlüssel muss irgendwo aufbewahrt werden : Am besten
    > optional beim Mailanbieter, jedoch per AES mit einem eigenen Passwort
    > verschlüsselt (123456 kann man sich besser merken als ein 4096bit großer
    > Schlüssel)
    >
    > 3. Henne-Ei-Problem : Kaum ein Maildienst hat das nativ implementiert ->
    > kaum einer nutzt das -> Niemand implementiert ...
    >
    > 4. Es ist nicht cool. Das Argument der Masse. Mit einem neuen Namen,
    > modernem Logo und weniger Technikgelaber sollte das jeder akzeptieren
    > können. Niemand interessiert es, welcher Algorithmus genutzt wird, das
    > verwirrt nur. Es muss aber klar sein, dass es einfach, sicher und für jeden
    > verständlich ist.

    +1 … würde ich so unterschrieben … wir haben offensichtlich ein Aufklärungsproblem in der breiten Öffentlichkeit. Keiner, der Probleme mit der Materie hat, wird zugeben, das er es nicht kann, also wird mit blöden Sprüchen und Abwiegelungen alles getan, das man nicht verschlüsseln muss. … 
    Ein gewisser Zwang wäre hie vielleicht angebracht.

  3. Re: PGP hat ZU viele Probleme

    Autor: dabbes 24.06.15 - 12:45

    Problem ist natürlich, dass die Mailsysteme und wie sie funktionieren nach "uralten" Methoden arbeiten und da traut sich kaum jemand ran.

  4. Re: PGP hat ZU viele Probleme

    Autor: thomas001le 24.06.15 - 12:56

    1. z.b. http://www.gushi.org/make-dns-cert/HOWTO.html nicht standardisiert, aber ein Ansatz

    2. Wo ist der Vorteil? Meinen verschlüsselten private key kann ich doch auch so irgendwo in die cloud schieben. Wenn ihn der mail provider hat, kommen nur leute auf die Idee der Provider könnte Mails ver- und entschlüsseln und ich muss ihm nur das Passwort zum private key schicken...das hebelt dann aber irgendwie Ende/Ende Verschlüsselung aus und man hat nicht viel mehr als De-Mail

    3. Das ist wohl ein Problem von jedem neuen Dienst....

    4. <ironie> Ja, es muss auch für Apple-Kunden letztendlich attraktiv sein </ironie>



    1 mal bearbeitet, zuletzt am 24.06.15 12:57 durch thomas001le.

  5. Re: PGP hat ZU viele Probleme

    Autor: Beeblox 24.06.15 - 13:01

    Port80 schrieb:
    --------------------------------------------------------------------------------
    > 2. Der private Schlüssel muss irgendwo aufbewahrt werden : Am besten
    > optional beim Mailanbieter, jedoch per AES mit einem eigenen Passwort
    > verschlüsselt (123456 kann man sich besser merken als ein 4096bit großer
    > Schlüssel)

    Angenommen, der Mailanbieter implementiert das: Dann schickst du ihm den privaten Schlüssel und der sagt dir dann „danke, ich verschlüssel das jetzt mit deinem Passwort und werde den Schlüssel im Klartext garantiert sofort vergessen“. Das ist nicht, wie Kryptografie funktioniert.

    Oder willst du den Schlüssel bei dir auf dem System verschlüsseln, bevor du ihn an den Mailanbieter übermittelst? Dann muss das ja quasi in deinem Client implementiert werden. *Und* du musst natürlich ein anderes Passwort benutzen als für deinen Mail-Account, sonst könnte dein Anbieter das Ding ja entschlüsseln, weil er dein Passwort kennt. Du hast also nachher zwei statt einem Passwort, die du dir merken musst, und jeder Client und jeder Server muss dieses Feature implementieren. Ich sehe nicht, aus welchem Grund dieser ganze Aufwand gerechtfertigt wäre.

    Warum nicht einfach den Schlüssel in der System-Keychain ablegen?

  6. Re: PGP hat ZU viele Probleme

    Autor: parafin 24.06.15 - 13:15

    Scheint wohl auch fuer Linuxanwender zu kompliziert sein, der Marktanteil von Linux ist hoeher als der Anteil verschluesselter Mails...

  7. Re: PGP hat ZU viele Probleme

    Autor: airstryke1337 24.06.15 - 13:27

    Port80 schrieb:
    --------------------------------------------------------------------------------
    > PGP hat folgende Probleme, die es nicht haben dürfte
    >
    > 1. Man muss den Schlüssel selbst auf einem Schlüsselserver hinterlegen -
    > besser wäre es, direkt beim Mailanbieter den pubKey hinterlegen zu lassen.
    > (X@y.com schickt an q@c.com eine Mail, bei c.com wird nach dem pubKey
    > gefragt und verschlüsselt)
    und wo ist da das problem? es ist halt noch nicht implementiert.

    > 2. Der private Schlüssel muss irgendwo aufbewahrt werden : Am besten
    > optional beim Mailanbieter, jedoch per AES mit einem eigenen Passwort
    > verschlüsselt (123456 kann man sich besser merken als ein 4096bit großer
    > Schlüssel)
    HTML5 local storage

    > 3. Henne-Ei-Problem : Kaum ein Maildienst hat das nativ implementiert ->
    > kaum einer nutzt das -> Niemand implementiert ...
    aber alle wollen es... echt strange

    > 4. Es ist nicht cool. Das Argument der Masse. Mit einem neuen Namen,
    > modernem Logo und weniger Technikgelaber sollte das jeder akzeptieren
    > können. Niemand interessiert es, welcher Algorithmus genutzt wird, das
    > verwirrt nur. Es muss aber klar sein, dass es einfach, sicher und für jeden
    > verständlich ist.
    +

    ...und wehe, du bietest (@golem: äh ja. kann aber auch n freudscher gewesen sein.) jetzt keinen mailanbieter mit automatisierter mailverschlüsselung an ;)



    2 mal bearbeitet, zuletzt am 24.06.15 13:30 durch airstryke1337.

  8. Re: PGP hat ZU viele Probleme

    Autor: airstryke1337 24.06.15 - 13:35

    airstryke1337 schrieb:
    --------------------------------------------------------------------------------
    > Port80 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > PGP hat folgende Probleme, die es nicht haben dürfte
    > >
    > > 1. Man muss den Schlüssel selbst auf einem Schlüsselserver hinterlegen -
    > > besser wäre es, direkt beim Mailanbieter den pubKey hinterlegen zu
    > lassen.
    > > (X@y.com schickt an q@c.com eine Mail, bei c.com wird nach dem pubKey
    > > gefragt und verschlüsselt)
    > und wo ist da das problem? es ist halt noch nicht implementiert.
    >
    > > 2. Der private Schlüssel muss irgendwo aufbewahrt werden : Am besten
    > > optional beim Mailanbieter, jedoch per AES mit einem eigenen Passwort
    > > verschlüsselt (123456 kann man sich besser merken als ein 4096bit großer
    > > Schlüssel)
    > HTML5 local storage
    >
    > > 3. Henne-Ei-Problem : Kaum ein Maildienst hat das nativ implementiert ->
    > > kaum einer nutzt das -> Niemand implementiert ...
    > aber alle wollen es... echt strange
    >
    > > 4. Es ist nicht cool. Das Argument der Masse. Mit einem neuen Namen,
    > > modernem Logo und weniger Technikgelaber sollte das jeder akzeptieren
    > > können. Niemand interessiert es, welcher Algorithmus genutzt wird, das
    > > verwirrt nur. Es muss aber klar sein, dass es einfach, sicher und für
    > jeden
    > > verständlich ist.
    > +
    >
    > ...und wehe, du bietest (@golem: äh ja. kann aber auch n freudscher gewesen
    > sein.) jetzt keinen mailanbieter mit automatisierter mailverschlüsselung an
    > ;)

    äh - moment - kann man mit "@golem" wirklich sagen, was ihr schreiben sollt?

  9. Re: PGP hat ZU viele Probleme

    Autor: Richtig Steller 24.06.15 - 14:00

    Port80 schrieb:
    --------------------------------------------------------------------------------
    > PGP hat folgende Probleme, die es nicht haben dürfte
    >
    > 1. Man muss den Schlüssel selbst auf einem Schlüsselserver hinterlegen -
    > besser wäre es, direkt beim Mailanbieter den pubKey hinterlegen zu lassen.
    > (X@y.com schickt an q@c.com eine Mail, bei c.com wird nach dem pubKey
    > gefragt und verschlüsselt)

    Du scheinst etwas grundlegendes nicht verstanden zu haben. PGP kann für Mails genutzt werden, ein PGP-Key muss aber mitnichten mit einer E-Mailadresse verknüpft sein.

    Schon einmal daran gedacht dass man verschlüsseln möchte ohne gleich zu verraten wer in der Lage ist zu entschlüssen?


    > 2. Der private Schlüssel muss irgendwo aufbewahrt werden : Am besten
    > optional beim Mailanbieter, jedoch per AES mit einem eigenen Passwort
    > verschlüsselt (123456 kann man sich besser merken als ein 4096bit großer
    > Schlüssel)

    Ganz dumme Idee oder naiv gedacht: Es ist unmöglich Daten irgendwo verschlüsselt abzulegen und auf diese sicher über ein drittes System zuzugreifen. Dieser MITM wird immer in der Lage sein das Kennwort, welches ich irgendwo eingeben muss, abzufangen und auszuleiten.

    Die ganzen Cloud-Dienste schreiben doch die Daten der Kunden AES256-verschlüsselt abzulegen. Dann müsste man sich doch eigentlich keine Sorgen machen! Schon einmal gefragt wieso diese Dienste trotz angeblicher Verschlüsselung in der Lage sind beim Login via Webinterface schönes Thumbnails zu erzeugen (das könnte theor. ja noch beim Speichern vorgeneriert werden) und Videos gleich streamen zu können? Ganz einfach: Die verschlüsselte Speicherung ist Bullshit bzw. speichern heutige phys. Datenträger (wie bspw. SSD) schon von Haus aus verschlüsselt. Solange der Key hierzu aber nicht alleine dem Kunden gehört...

    Jetzt schaue dir mal SpiderOak an. Den Dienst den Snowden einmal empfohlen hatte. Wieso sind da solche Dinge nicht möglich bzw. kommen da fette Warnungen wenn du das dennoch willst? Weil die dir nicht verheimlichen, dass sie dafür die verschlüsselten Daten jetzt temporär entschlüsseln müssen (damit liegen die Daten in Klartext irgendwo) und dass es eben eine ganz dumme Idee ist via Browser etc. da seine Passphrase einzugeben (selbst wenn sie da per Challenge Response Verfahren arbeiten, der Browser bekommt das Kennwort. Einen Browser zu "ownen" ist heute kein Problem. Mindestens alle 30 Tage öffnen sich neue Möglichkeiten (siehe die Changelogs der Browser-Updates)...

    Ich bin ehrlich gesagt fassungslos das Nutzer meinen Schlüssel in die Cloud legen zu wollen und kein Problem haben den Schlüssel für den Schlüssel via Browser/jeglichen Endgerät einzugeben. Dies ist vermutlich das Hauptproblem: Fehlendes Wissen.

    Leute Leute... ihr glaubt vermutlich auch, dass Android-Anwendungen untereinander sicher sind. Dass das was innerhalb einer Anwendung passiert in der Anwendung bleibt. Es für andere installierte Anwendungen keine Möglichkeit gibt da Zugriff zu nehmen... wacht auf.


    Es mag unschön sein, aber Sicherheit und Komfort steht in aller Regel im Widerspruch.

    Sicherheit kann nur dann funktionieren wenn jeder weiß wieso etwas gerade "sicher" ist. Worauf die Sicherheit beruht. Denn dann sind die beteiligten Personen in der Lage zu erkennen, wenn etwas unsicher wird...

    Aber vermutlich ist die Mehrheit gar nicht wirklich an "Sicherheit" interessiert, wenn das Aufwand bedeutet. Ähnlich wie bei dem aktuellen HTTPS-Wahn: Klar, sensible Daten per HTTP zu übertragen ist doof. Aber gleich Zertifikats-Pinning? Proxies die SSL-Verkehr aufbrechen haben ihre Berechtigung. In Zukunft wird es immer schwerer - Dank Verschlüsselung - festzustellen, was eine App alles an Daten heraus trägt.


    Aber Hauptsache man musste sich nie mit dem Kram auseinander setzen. Es ist immer schön wenn "andere" sich um die Sicherheit kümmern sollen. Das beruhigt und im Fehlerfalle kann ich auf die auch noch mit dem Finger zeigen!!1111!

  10. Re: PGP hat ZU viele Probleme

    Autor: airstryke1337 24.06.15 - 14:11

    Richtig Steller schrieb:
    --------------------------------------------------------------------------------
    > Port80 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > PGP hat folgende Probleme, die es nicht haben dürfte
    > >
    > > 1. Man muss den Schlüssel selbst auf einem Schlüsselserver hinterlegen -
    > > besser wäre es, direkt beim Mailanbieter den pubKey hinterlegen zu
    > lassen.
    > > (X@y.com schickt an q@c.com eine Mail, bei c.com wird nach dem pubKey
    > > gefragt und verschlüsselt)
    >
    > Du scheinst etwas grundlegendes nicht verstanden zu haben. PGP kann für
    > Mails genutzt werden, ein PGP-Key muss aber mitnichten mit einer
    > E-Mailadresse verknüpft sein.
    >
    > Schon einmal daran gedacht dass man verschlüsseln möchte ohne gleich zu
    > verraten wer in der Lage ist zu entschlüssen?
    >
    > > 2. Der private Schlüssel muss irgendwo aufbewahrt werden : Am besten
    > > optional beim Mailanbieter, jedoch per AES mit einem eigenen Passwort
    > > verschlüsselt (123456 kann man sich besser merken als ein 4096bit großer
    > > Schlüssel)
    >
    > Ganz dumme Idee oder naiv gedacht: Es ist unmöglich Daten irgendwo
    > verschlüsselt abzulegen und auf diese sicher über ein drittes System
    > zuzugreifen. Dieser MITM wird immer in der Lage sein das Kennwort, welches
    > ich irgendwo eingeben muss, abzufangen und auszuleiten.
    >
    > Die ganzen Cloud-Dienste schreiben doch die Daten der Kunden
    > AES256-verschlüsselt abzulegen. Dann müsste man sich doch eigentlich keine
    > Sorgen machen! Schon einmal gefragt wieso diese Dienste trotz angeblicher
    > Verschlüsselung in der Lage sind beim Login via Webinterface schönes
    > Thumbnails zu erzeugen (das könnte theor. ja noch beim Speichern
    > vorgeneriert werden) und Videos gleich streamen zu können? Ganz einfach:
    > Die verschlüsselte Speicherung ist Bullshit bzw. speichern heutige phys.
    > Datenträger (wie bspw. SSD) schon von Haus aus verschlüsselt. Solange der
    > Key hierzu aber nicht alleine dem Kunden gehört...
    >
    > Jetzt schaue dir mal SpiderOak an. Den Dienst den Snowden einmal empfohlen
    > hatte. Wieso sind da solche Dinge nicht möglich bzw. kommen da fette
    > Warnungen wenn du das dennoch willst? Weil die dir nicht verheimlichen,
    > dass sie dafür die verschlüsselten Daten jetzt temporär entschlüsseln
    > müssen (damit liegen die Daten in Klartext irgendwo) und dass es eben eine
    > ganz dumme Idee ist via Browser etc. da seine Passphrase einzugeben (selbst
    > wenn sie da per Challenge Response Verfahren arbeiten, der Browser bekommt
    > das Kennwort. Einen Browser zu "ownen" ist heute kein Problem. Mindestens
    > alle 30 Tage öffnen sich neue Möglichkeiten (siehe die Changelogs der
    > Browser-Updates)...
    >
    > Ich bin ehrlich gesagt fassungslos das Nutzer meinen Schlüssel in die Cloud
    > legen zu wollen und kein Problem haben den Schlüssel für den Schlüssel via
    > Browser/jeglichen Endgerät einzugeben. Dies ist vermutlich das
    > Hauptproblem: Fehlendes Wissen.
    >
    > Leute Leute... ihr glaubt vermutlich auch, dass Android-Anwendungen
    > untereinander sicher sind. Dass das was innerhalb einer Anwendung passiert
    > in der Anwendung bleibt. Es für andere installierte Anwendungen keine
    > Möglichkeit gibt da Zugriff zu nehmen... wacht auf.
    >
    > Es mag unschön sein, aber Sicherheit und Komfort steht in aller Regel im
    > Widerspruch.
    >
    > Sicherheit kann nur dann funktionieren wenn jeder weiß wieso etwas gerade
    > "sicher" ist. Worauf die Sicherheit beruht. Denn dann sind die beteiligten
    > Personen in der Lage zu erkennen, wenn etwas unsicher wird...
    >
    > Aber vermutlich ist die Mehrheit gar nicht wirklich an "Sicherheit"
    > interessiert, wenn das Aufwand bedeutet. Ähnlich wie bei dem aktuellen
    > HTTPS-Wahn: Klar, sensible Daten per HTTP zu übertragen ist doof. Aber
    > gleich Zertifikats-Pinning? Proxies die SSL-Verkehr aufbrechen haben ihre
    > Berechtigung. In Zukunft wird es immer schwerer - Dank Verschlüsselung -
    > festzustellen, was eine App alles an Daten heraus trägt.
    >
    > Aber Hauptsache man musste sich nie mit dem Kram auseinander setzen. Es ist
    > immer schön wenn "andere" sich um die Sicherheit kümmern sollen. Das
    > beruhigt und im Fehlerfalle kann ich auf die auch noch mit dem Finger
    > zeigen!!1111!

    du vergisst, dass clientseitige verschlüsselung eigentlich standart ist. (zumindest, wenn man die letzten paar jahre über golem gelesen hat)

  11. Re: PGP hat ZU viele Probleme

    Autor: Richtig Steller 24.06.15 - 16:32

    airstryke1337 schrieb:
    --------------------------------------------------------------------------------
    > du vergisst, dass clientseitige verschlüsselung eigentlich standart ist.
    > (zumindest, wenn man die letzten paar jahre über golem gelesen hat)

    Deine Antwort verstehe ich leider nicht. Worauf beziehst du sie? Wo sei Client-seitige Verschlüsselung Standard?

    - In der Cloud?
    - Bei Apps?
    - ...?

  12. Re: PGP hat ZU viele Probleme

    Autor: cpt.dirk 28.06.15 - 14:30

    Port80 schrieb:
    --------------------------------------------------------------------------------
    > PGP hat folgende Probleme, die es nicht haben dürfte
    >
    > 1. Man muss den Schlüssel selbst auf einem Schlüsselserver hinterlegen -
    > besser wäre es, direkt beim Mailanbieter den pubKey hinterlegen zu lassen.
    > (X@y.com schickt an q@c.com eine Mail, bei c.com wird nach dem pubKey
    > gefragt und verschlüsselt)

    Was ist dabei der Vorteil? Wenn die Mailclients automatisch auf ein- oder zwei Standardschlüsselservern nachsehen, geht das doch genauso. Diese werden im Regelfass langfristig gewartet und stehen jederzeit zur Verfügung, auch für den Rückzug von Schlüsseln, was bei Mailanbietern nicht unbedingt der Fall ist.

    > 2. Der private Schlüssel muss irgendwo aufbewahrt werden : Am besten
    > optional beim Mailanbieter, jedoch per AES mit einem eigenen Passwort
    > verschlüsselt (123456 kann man sich besser merken als ein 4096bit großer
    > Schlüssel)

    Auf keinen Fall.

    > 3. Henne-Ei-Problem : Kaum ein Maildienst hat das nativ implementiert ->
    > kaum einer nutzt das -> Niemand implementiert ...

    Muss auch nicht sein, wenn die Implementierungen in den geläufigen Mailclients auf Stand gebracht werden.

    > 4. Es ist nicht cool. Das Argument der Masse. Mit einem neuen Namen,
    > modernem Logo und weniger Technikgelaber sollte das jeder akzeptieren
    > können. Niemand interessiert es, welcher Algorithmus genutzt wird, das
    > verwirrt nur. Es muss aber klar sein, dass es einfach, sicher und für jeden
    > verständlich ist.

    Nicht innerhalb von 2 Minuten verständlich = uncool, natürlich.
    Früher konnten die Leute ihre Autos noch selber reparieren, heute schaffen sie es nicht mehr, weil zu komplexe Technik, Ok. Aber Verschlüsselung wird durch graphische Tools immer einfacher. Ich sage nicht, dass da nicht noch großes Verbesserungspotential vorliegt, aber wer WILL, der kann.

    Vielleicht sollte man Verschlüsselungs-Know-How einfach als natürliche Erweiterung des Grundwissens ansehen, das Einmaleins der Computergeneration. Genauso wie: warum darf ich nicht jeden x-beliebigen Anhang öffnen oder worauf lasse ich mich bei Facebook, Whatsapp und Co. wirklich ein.

  13. Re: PGP hat ZU viele Probleme

    Autor: ikhaya 28.06.15 - 16:22

    Wenn du einen öffentlichen Schlüssel auf einem Schlüsselserver hinterlegst hast du momentan das Problem dass das jeder andere Bewohner dieser Erde auch machen könnte an deiner Stelle. Siehe dazuhttp://www.heise.de/ct/ausgabe/2015-6-Editorial-Lasst-PGP-sterben-2551008.html .
    Es gibt Spaßvögel die für andere Leute öffentliche Schlüssel hochladen und damit ist die Benutzbarkeit des Systems beeinträchtigt. Diese falschen Schlüssel kriegst du nicht wieder aus dem Netz.
    Wenn du das deinem E-Mail-Anbieter überlässt kann mit einer gewissen Sicherheit davon ausgegangen werden, dass es der richtige Schlüssel ist und der Eigentümer des dazugehörigen privaten Schlüssels die E-Mail auch lesen kann am Ende.

  14. Re: PGP hat ZU viele Probleme

    Autor: cpt.dirk 29.06.15 - 20:10

    ikhaya schrieb:
    --------------------------------------------------------------------------------

    > Es gibt Spaßvögel die für andere Leute öffentliche Schlüssel hochladen und
    > damit ist die Benutzbarkeit des Systems beeinträchtigt. Diese falschen
    > Schlüssel kriegst du nicht wieder aus dem Netz.
    > Wenn du das deinem E-Mail-Anbieter überlässt kann mit einer gewissen
    > Sicherheit davon ausgegangen werden, dass es der richtige Schlüssel ist und
    > der Eigentümer des dazugehörigen privaten Schlüssels die E-Mail auch lesen
    > kann am Ende.

    Das stimmt natürlich. Da müsste eine Lösung für das System der Schlüsselserver her, bzw. eine Möglichkeit auf Revocation-Antrag ohne RevKey.

    Vielleicht könnte aber auch der Mailprovider gleich beim Anlegen des Kontos den öffentlichen Schlüssel vom User entgegennehmen (dann wäre der Anreiz einen solchen gleich zu erzeugen auch gegeben) und an die Schlüsselserver übergeben. Dann müssten die Mailclients das aber auch ab Werk unterstützen.

    Entweder könnten dann die Keyserver die Schlüssel nur noch über die Mailprovider annehmen (was ungut wäre), oder eine Schlüssel-Revocation ohne RevKey nur von zertifizierten Mailprovidern, bei denen man dann das Zurückziehen beantragen kann.

    Wobei natürlich die Frage ist, wie es bei einem gefakten oder kompromittierten Mailprovider aussieht - der könnte für ein schönes Durcheinander sorgen, was auch für die Verteilung der PubKeys via Provider gilt.

    Und man muss natürlich im Kontext millionenfach gehackter Mailkonten in Betracht ziehen, dass hierüber zumindest zeitweise ebenfalls gefakte PubKeys in Umlauf gebracht werden können (evtl. sogar längerere Zeit unbemerkt).

    Böswillig zurückgezogene Zertifikate sind vermutlich weniger schlimm, als gefakte.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Hochschule Furtwangen, Furtwangen
  2. CSB-SYSTEM AG, Geilenkirchen
  3. Folkwang Universität der Künste, Essen, Köln
  4. Schaeffler Technologies AG & Co. KG, Herzogenaurach

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Overwatch GOTY XBO für 15€ und Blu-ray-Angebote)
  2. 99,90€ + Versand (Vergleichspreis 129,85€ + Versand)
  3. (u. a. Hell Let Loose für 15,99€, Hitman 2 für 15,49€ und PSN Card 25 Euro [DE] für 21,99€)
  4. (u. a. SanDisk SSD Plus 1 TB für 88€ + Versand oder kostenlose Marktabholung)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Smarte Wecker im Test: Unter den Blinden ist der Einäugige König
Smarte Wecker im Test
Unter den Blinden ist der Einäugige König

Einen guten smarten Wecker zu bauen, ist offenbar gar nicht so einfach. Bei Amazons Echo Show 5 und Lenovos Smart Clock fehlen uns viele Basisfunktionen. Dafür ist einer der beiden ein besonders preisgünstiges und leistungsfähiges smartes Display.
Ein Test von Ingo Pakalski

  1. Nest Hub im Test Google vermasselt es 1A

Erdbeobachtung: Satelliten im Dienst der erneuerbaren Energien
Erdbeobachtung
Satelliten im Dienst der erneuerbaren Energien

Von oben ist der Blick auf die Erde am besten. Satelliten werden deshalb für die Energiewende eingesetzt: Mit ihnen lassen sich beispielsweise die Standorte für Windkraftwerke oder Solaranlagen bestimmen sowie deren Ertrag prognostizieren.
Ein Bericht von Jan Oliver Löfken

  1. Rocketlab Kleine Rakete wird wiederverwendbar und trotzdem teurer
  2. Space Data Highway Esa bereitet Laser-Kommunikationsstation für den Start vor
  3. Iridium Certus Satelliten-Breitbandnetz startet mit 350 bis 700 KBit/s

Zephyrus G GA502 im Test: Das Gaming-Notebook, das auch zum Arbeiten taugt
Zephyrus G GA502 im Test
Das Gaming-Notebook, das auch zum Arbeiten taugt

Mit AMDs Ryzen 7 und Nvidia-GPU ist das Zephyrus G GA502 ein klares Gaming-Gerät. Überraschenderweise eignet es sich aber auch als mobiles Office-Notebook. Das liegt an der beeindruckenden Akkulaufzeit.
Ein Test von Oliver Nickel

  1. Vivobook (X403) Asus packt 72-Wh-Akku in günstigen 14-Zöller
  2. ROG Swift PG35VQ Asus' 35-Zoll-Display nutzt 200 Hz, HDR und G-Sync
  3. ROG Gaming Phone II Asus plant neue Version seines Gaming-Smartphones

  1. Taleworlds: Mount and Blade 2 ist 2020 nach acht Jahren spielbar
    Taleworlds
    Mount and Blade 2 ist 2020 nach acht Jahren spielbar

    Mit dem Schwert und dem Pferd können Fans der Mittelaltersimulation Mount and Blade den langersehnten zweiten Teil spielen. Diese Version wird allerdings im Early Access erscheinen und von daher nicht fertig sein. Zumindest geht es voran.

  2. Disney: Obi Wan Kenobi kehrt ab 2020 zurück
    Disney
    Obi Wan Kenobi kehrt ab 2020 zurück

    Ewan McGregor selbst hat es auf der Messe D23 Expo bestätigt: Er wird als Obi Wan Kenobi in der Star-Wars-Serie Kenobi zu sehen sein. Disney will den Drehstart für das Jahr 2020 ansetzen.

  3. Spielebranche: SAP analysiert E-Sportler
    Spielebranche
    SAP analysiert E-Sportler

    Gamescom 2019 Zwischen Microsoft mit der Xbox und Bethesda mit Doom Eternal in Halle 8 ist SAP mit einem eigenen Stand auf der Spielemesse vertreten. Golem.de hat sich einmal angeschaut, was das Softwarehaus dort macht.


  1. 11:35

  2. 10:51

  3. 10:27

  4. 18:00

  5. 18:00

  6. 17:41

  7. 16:34

  8. 15:44