Key wird nicht erkannt obwohl vorhanden

  • Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
    * Thunderbird-Version: 31.6.0
    * Betriebssystem + Version: Win 7 x64
    * Kontenart (POP / IMAP): IMAP
    * Postfachanbieter (z.B. GMX): z.B. riseup.net
    * S/MIME oder PGP: GPG4Win
    * Eingesetzte Antivirensoftware: NOD32
    * Firewall (Betriebssystem-intern/Externe Software):


    Vor ein paar Tagen hab ich meinen Rechner vollkommen neu aufgesetzt und es funktioniert eigentlich auch alles bis auf Teile von GPG / Enigmail


    Ich bekam heute eine Mail die signiert war und da der Schlüssel angeblich nicht vorhanden war wollte ich ihn importieren. An der Stelle geht der Ärger schon los, denn ich bekam folgende kryptische Meldung angezeigt


    Also habe ich Kleopatra gestartet und sie da, der Key war vorhanden und auch nicht abgelaufen


    also könnte ein Fehler vorliegen = Selbsttest, doch der sagt



    und bevor nun jemand fragt


    Was das ärgerliche daran ist, ist der Umstand, dass ich mich z,B. durch Mitwirkung auf Cryptopartys für das Verschlüsseln stark mache und dann scheitert die Technik derart kläglich ohne das es einen erkennbaren Grund / Anwenderfehler gibt. Wäre nett wenn jemand nen Tipp für eine Fehlerbeseitigung hat.

    Trust no one. Trust nothing. Assume everyone else is a malicious actor

    Edited once, last by Togijak ().

  • @graba


    OK = erledigt (wobei das aus der Mail stammt)


    Quote


    Hi all,today, I updated the overview of our received Gpg4win donations:Total donations (since 2006): 10.230,15 EUR (= 448 donations)Overview per year: 2015: 3308,36 EUR (Q1, until 2015-03-31, 109 donations) 2014: 1585,89 EUR 2013: 2056,80 EUR 2012: 1489,80 eUR 2011: 513,00 EUR 2010: 582,50 EUR 2009: 257,06 EUR 2008: 43,99 EUR 2007: 324,75 EUR 2006: 68,00 EUR(VAT will be deducted.)You can find the current list of sponsors here:(250 of 448 sponsors have allowed to publish the names.) http://gpg4win.org/donate.htmlMany thanks to all sponsors!!!You like Gpg4win? Help the Gpg4win initiative and donate, please!Best regards,Emanuel

    und damit ziemlich öffentlich (bzw. nicht vertraulich) ist.

    Trust no one. Trust nothing. Assume everyone else is a malicious actor

  • und bevor nun jemand fragt

    Die durchaus wichtige Information zur verwendetet GnuPG-Version hast Du leider nicht geliefert :mrgreen:


    Wenn Du die Fehlermeldung "amor-keys-failed" in eine Suchmaschine Deines Vertrauens eingibst, dann erhältst Du zahlreiche Treffer. Siehe z.B. hier: http://lists.gnutls.org/piperm…2015-February/029524.html


    Zumindest die kryptische Fehlermeldung scheint ein bug in GPG zu sein. Vielleicht fragst Du besser gleich direkt bei den GPG-lern nach?

  • Gern ein zweites Mal:

    Zumindest die kryptische Fehlermeldung scheint ein bug in GPG zu sein. Vielleicht fragst Du besser gleich direkt bei den GPG-lern nach?

    Die Fehlermeldung tritt laut der verlinkten bug-Meldung im Zusammenhang mit einem Refresh auf. Genau das hat Du ja offenbar versucht. Ja, ich habe gesehen, dass dieser Fehler in der 2.0.27 behoben sein soll. Auch deshalb der Hinweis auf den Support direkt bei GPG. Wir hier können das nicht fixen.


    Soweit es den Auslöser betrifft, also weshalb Du die Signatur trotz eines bereits vorhandenen öffentlich Schlüssels nicht verifizieren konntest, so solltest auch dazu einmal beim Absender nachfragen. Vielleicht hat er zum Signieren einen anderen privaten Schlüssel verwendet zu welchem Dir der öffentliche fehlt.
    Du kannst auch zum Test den vorhandenen öffentlichen Schlüssel löschen und ihn dann neu importieren.

  • @'SusiTux


    Genau das hab ich gemacht und folgende Antwort erhalten


    Quote

    Der Key ist also bereits vorhanden. Warum Emanuels Signatur nicht überprüft werden kann kann ich anhand der Screenshots aber nicht beurteilen. Da hier Enigmail zum Einsatz kommt, hat Gpg4win damit nicht viel zu tun - es wird lediglich GnuPG daraus benutzt. Enigmail stellt es aber alles selbst dar. Am besten mal auf der Enigmail Liste nachfragen. Ich kann mal ins Blaue vermuten, dass Enigmail, die von Mailman angehangen MIME Teile (Informationen zur Liste), falsch erkennt und versucht diese auch zu verifizieren. Oder der übliche Mailman/Python Bug der gelegentlich Mails leicht verändert hat wieder zugeschlagen.

    Unabhängig von dem persönlichen Problem ist das schlicht und ergreifend der Mist, der verhindert, dass Verschlüsselung nicht mehr Anhänger findet. Ich stimme in der Zwischenzeit mit Jürgen Schmidt überein, dass eine bessere Lösung gefunden werden muss.


    Das witzige an der Geschichte ist, dass der Key bei Verwendung von Tails verifiziert werden kann = am möglicherweise falschen Key liegt es also nicht..

    Trust no one. Trust nothing. Assume everyone else is a malicious actor

  • Ich denke, Du bringst ein paar Dinge durcheinander. Da ist zum einen die kryptische Fehlermeldung. Dazu gibt es den verlinkten Bug bei GPG und die Aussage, dass er behoben sei.
    Dann ist da noch wichtigere die Frage, weshalb der vorhandene Schlüssel nicht erkannt wird, sofern Du denn wirklich den richtigen bereits importiert hattest hattest. Das kann durchaus an Enigmail liegen. Allerdings habe ich diesen Fehler bisher nicht beobachten können.


    Dass der Key, den Du versuchst zu importieren, bereits vorhanden ist, wussten wir schon. Das sieht man an der Fehlermeldung aber auch daran, dass der erwähnte GPG-bug, wie erwähnt, ja beim Refresh austritt.


    Hast Du dies ebenfalls versucht?

    Du kannst auch zum Test den vorhandenen öffentlichen Schlüssel löschen und ihn dann neu importieren.


    Falls das nicht zum Erfolg führt, dann solltest Du Dich direkt an das Team dort wenden. Auch bugs in Enigmail können wir hier nicht fixen.


    Meckern hilft übrigens wenig. Dass weder PGP/Enigmail noch S/MIME der Weisheit letzter Schluss sind, ist unbestritten. Zum gegenwärtigen Zeitpunkt sind es aber die verbreiteten Verfahren, wenn man dann überhaupt von Verbreitung sprechen will. Die diskutierten alternativen Modelle, wie z.B. auch in dem von Dir verlinkten Artikel erwähnt, sind aber auch nicht das Gelbe vom Ei. Wenn man platt formulieren will, dann gibt es Einfachheit in der Regel nur auf Kosten der Vertrauenswürdigkeit. Ich fühle mich jedenfalls wohler, wenn nur ich allein im Besitz meiner privaten Schlüssel bin.

  • Ich fühle mich jedenfalls wohler, wenn nur ich allein im Besitz meiner privaten Schlüssel bin.

    @SusiTux


    womit wir schon wieder bei einer extremen Unsicherheit von GPG angelangt sind, denn der private Key Ring liegt vollkommen ungeschützt an einer Stelle auf der Platte, wo ihn jeder Angreifer (nein das muss kein Mensch, dass kann auch ein (Staats)Trojaner sein) schnell finden kann.Das ist im Moment nichts Besseres gibt stimmt natürlich, aber an der Stelle sollten wir abbrechen, denn all das hat mit dem auslösenden Problem nichts zu tun.

    Trust no one. Trust nothing. Assume everyone else is a malicious actor

  • womit wir schon wieder bei einer extremen Unsicherheit von GPG angelangt sind, denn der private Key Ring liegt vollkommen ungeschützt an einer Stelle auf der Platte, wo ihn jeder Angreifer [...] schnell finden kann.


    aber an der Stelle sollten wir abbrechen,

    Gerne, aber nicht mit einer solch verdrehten Darstellung. Dein Argument spricht eher für das Gegenteil. Wo bitte ist ein privater Key besser aufgehoben, bei irgendeinem Provider in der Cloud oder auf Deinem eigenen Rechner, auf dem Du die Platte zusätzlich verschlüsseln kannst?