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. Dataport, verschiedene Standorte
  2. über experteer GmbH, Nürnberg
  3. Caritas Wohn- und Werkstätten im Erzbistum Paderborn e. V., Paderborn
  4. CSB-SYSTEM AG, Geilenkirchen bei Aachen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. 49,70€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ryzen 7 3800X im Test: Der schluckt zu viel
Ryzen 7 3800X im Test
"Der schluckt zu viel"

Minimal mehr Takt, vor allem aber ein höheres Power-Budget für gestiegene Frequenzen unter Last: Das war unsere Vorstellung vor dem Test des Ryzen 7 3800X. Doch die Achtkern-CPU überrascht negativ, weil AMD es beim günstigeren 3700X bereits ziemlich gut meinte.
Ein Test von Marc Sauter

  1. Agesa 1003abba Microcode-Update taktet Ryzen 3000 um 50 MHz höher
  2. Agesa 1003abb Viele ältere Platinen erhalten aktuelles UEFI für Ryzen 3000
  3. Ryzen 5 3400G und Ryzen 3 3200G im Test Picasso passt

Astronomie: K2-18b ist weder eine zweite Erde noch super
Astronomie
K2-18b ist weder eine zweite Erde noch super

Die Realität sieht anders aus, als manche Überschrift vermuten lässt. Die neue Entdeckung von Wasser auf einem Exoplaneten deutet nicht auf Leben hin, dafür aber auf Probleme im Wissenschaftsbetrieb.
Von Frank Wunderlich-Pfeiffer

  1. Interview Heino Falcke "Wir machen Wettermodelle für schwarze Löcher"

Verkehrssicherheit: Die Lehren aus dem tödlichen SUV-Unfall
Verkehrssicherheit
Die Lehren aus dem tödlichen SUV-Unfall

Soll man tonnenschwere SUV aus den Innenstädten verbannen? Oder sollten technische Systeme schärfer in die Fahrzeugsteuerung eingreifen? Nach einem Unfall mit vier Toten in Berlin mangelt es nicht an radikalen Vorschlägen.
Eine Analyse von Friedhelm Greis

  1. Torc Robotics Daimler-Tochter testet selbstfahrende Lkw
  2. Edag Citybot Wandelbares Auto mit Rucksackmodulen gegen Verkehrsprobleme
  3. Tusimple UPS testet automatisiert fahrende Lkw

  1. Wirtschaftsförderung: Agentur für Sprunginnovationen kommt nach Leipzig
    Wirtschaftsförderung
    Agentur für Sprunginnovationen kommt nach Leipzig

    Nach dem Vorbild der Darpa will die Bundesregierung künftig innovative Projekte fördern. Damit erhält bereits die zweite Innovationsagentur des Bundes ihren Sitz in Ostdeutschland.

  2. UPC: Größter Kabelnetzbetreiber führt 1 GBit/s im ganzen Netz ein
    UPC
    Größter Kabelnetzbetreiber führt 1 GBit/s im ganzen Netz ein

    Bei UPC wird noch in diesem Monat 1 GBit/s im gesamten Netz angeboten, was in Deutschland noch keiner aus der Kabelnetz-Branche geschafft hat. Auch Sunrise baut sein 5G-Angebot als Glasfaser-Ersatz aus.

  3. Intel-Prozessor: Core i9-9900KS tritt mit 127 Watt TDP an
    Intel-Prozessor
    Core i9-9900KS tritt mit 127 Watt TDP an

    Acht Kerne mit bis zu 5 GHz für alle: Der Core i9-9900KS erscheint im Oktober 2019 und wird die vorerst schnellste Gaming-CPU. Erste Firmware-Updates zeigen, dass Intel die nominelle Verlustleistung von 95 Watt auf 127 Watt anhebt. Für vollen Takt wird das aber nicht reichen.


  1. 18:11

  2. 17:51

  3. 15:54

  4. 15:37

  5. 15:08

  6. 15:00

  7. 14:53

  8. 14:40