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.

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Bundeskriminalamt, Wiesbaden
  2. Animus GmbH & Co. KG, Ratingen
  3. Techniker Krankenkasse, Hamburg
  4. DASGIP Information and Process Technology GmbH, Jülich

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 469€
  2. 80,90€ + Versand
  3. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Watch Dogs Legion angespielt: Eine Seniorin als Ein-Frau-Armee
Watch Dogs Legion angespielt
Eine Seniorin als Ein-Frau-Armee

E3 2019 Elitesoldaten brauchen wir nicht - in Watch Dogs Legion hacken und schießen wir auch als Pensionistin für den Widerstand. Beim Anspielen haben wir sehr über die ebenso klapprige wie kampflustige Oma Gwendoline gelacht.


    Elektromobilität: Wohin mit den vielen Akkus?
    Elektromobilität
    Wohin mit den vielen Akkus?

    Akkus sind die wichtigste Komponente von Elektroautos. Doch auch, wenn sie für die Autos nicht mehr geeignet sind, sind sie kein Fall für den Schredder. Hersteller wie Audi testen Möglichkeiten, sie weiterzuverwenden.
    Ein Bericht von Dirk Kunde

    1. Proterra Elektrobushersteller vermietet Akkus zur Absatzförderung
    2. Batterieherstellung Kampf um die Zelle
    3. US CPSC HP muss in den USA nochmals fast 80.000 Akkus zurückrufen

    Vernetztes Fahren: Wer hat uns verraten? Autodaten
    Vernetztes Fahren
    Wer hat uns verraten? Autodaten

    An den Daten vernetzter Autos sind viele Branchen und Firmen interessiert. Die Vorschläge zu Speicherung und Zugriff auf die Daten sind jedoch noch nebulös. Und könnten den Fahrzeughaltern große Probleme bereiten.
    Eine Analyse von Friedhelm Greis

    1. Neues Geschäftsfeld Huawei soll an autonomen Autos arbeiten
    2. Taxifahrzeug Volvo baut für Uber Basis eines autonomen Autos
    3. Autonomes Fahren Halter sollen bei Hackerangriffen auf Autos haften

    1. Docsis 3.1 Remote-MACPHY: 10 GBit/s-System für Kabelnetz besteht Modem-Test
      Docsis 3.1 Remote-MACPHY
      10 GBit/s-System für Kabelnetz besteht Modem-Test

      Distributed CCAP Nodes bringen 10 GBit/s im Kabelnetz. Ein Modemtest für Docsis 3.1 von DEV Systemtechnik ist dazu jetzt erfolgreich gewesen.

    2. Sindelfingen: Mercedes und Telefónica Deutschland errichten 5G-Netz
      Sindelfingen
      Mercedes und Telefónica Deutschland errichten 5G-Netz

      In Sindelfingen wird 5G in der laufenden Produktion eingesetzt. Es geht um die Ortung von Produkten und die Verarbeitung großer Datenmengen (Data Shower).

    3. Load Balancer: HAProxy 2.0 bringt Neuerungen für HTTP und die Cloud
      Load Balancer
      HAProxy 2.0 bringt Neuerungen für HTTP und die Cloud

      In der neuen LTS-Version 2.0 liefern die Entwickler des Open-Source-Load-Balancers HAProxy unter anderem mit einem Kubernetes Ingress Controller und einer Data-Plane-API aus. Auch den Linux-Support hat das Team vereinheitlicht.


    1. 18:42

    2. 16:53

    3. 15:35

    4. 14:23

    5. 12:30

    6. 12:04

    7. 11:34

    8. 11:22