PGP, wie entschluesseln mit expired key
Achim Stump
ich setze PGP 5.5.3i f. Win95 ein.
Vor einiger Zeit habe ich mal einen Schluessel mit Verfallsdatum
(31.12.1998) erstellt und damit Dateien auf meiner HD verschluesselt
in der Annahme, dass ich zwar nach dem Verfallsdatum den Key nicht
mehr zum verschluesseln wohl aber noch zum entschluesseln verwenden
koennte. Nun bekomme ich aber die Fehlermeldung:
"Message was encrypted to the following public key(s):
x@y.z
It is not possible to decrypt this message because your keyring does
not contain usable private key(s) corresponding to any of the above
public key(s)."
Selbstverstaendlich enthaelt mein secring.skr noch den passenden
Private Key - ich kann ihn sogar noch exportieren. Aber ich komme
jetzt an meine eigenen Dateien nicht mehr dran (Trick 17 mit
Selbstueberlistung?).
Gibt es irgendeine Moeglichkeit, mit dem verfallenen Schluessel noch
zu entschluesseln: mit 5.5.3i oder brauche ich dafuer 2.x?
Fuer jeden sachdienlichen Hinweis bin ich dankbar!!!
Achim
Mirko Zeibig
>
> Gibt es irgendeine Moeglichkeit, mit dem verfallenen Schluessel noch
> zu entschluesseln: mit 5.5.3i oder brauche ich dafuer 2.x?
> Fuer jeden sachdienlichen Hinweis bin ich dankbar!!!
Gruss
Mirko
--
mailto:mirko....@gmx.de
surfto:http://sites.inka.de/picard
Tim Niemueller
hast du die Möglichkeit, weitere Subkeys anzulegen. Wenn du einen neuen
Subkey (natürlich nicht expired) anlegst, dann könte ich mir denken, dass du
damit die Nachricht entschlüsseln kannst. evtl. musst du dann die gleiche
Benutzer ID angeben...
Tim
==================================================================
Tim Niemueller <t...@niemueller.de> www.niemueller.de
--> PGP-IDs und Fingerprints <--------- Get on Homepage! ---------
(DH 0x68238B57) C343 4EDC 1930 7043 C617 E98A 0817 DCDC 6823 8B57
(RSA 0x727B2BB7) 4244 5CBB 67CC 7DC4 71B2 6EB7 149F 2585
Lutz Donnerhacke
>Achim Stump wrote:
>> Gibt es irgendeine Moeglichkeit, mit dem verfallenen Schluessel noch
>> zu entschluesseln: mit 5.5.3i oder brauche ich dafuer 2.x?
>> Fuer jeden sachdienlichen Hinweis bin ich dankbar!!!
>Uhr zurueckstellen ;-)?!?
Prima Idee. Ja. Andere Varianten sind so kleinigkeiten, wie Patches an den
Keys oder im Source.
Achim Stump
<mirko....@picard.inka.de> wrote:
>Uhr zurueckstellen ;-)?!?
Jawoll! Prima workaround.
Die einfachen Loesungen sind meist die schoensten.
Aber mal im Ernst: Ist das ein Bug oder ein Feature, dass man Dateien
nicht mehr entschluesseln kann, wenn der zur Verschluesselung
verwendete Key zwischenzeitlich ueber das Verfallsdatum gekommen ist?
Bisher kann ich darin keinen besonderen Nutzen erkennen.
Achim
Lutz Donnerhacke
>Aber mal im Ernst: Ist das ein Bug oder ein Feature, dass man Dateien
>nicht mehr entschluesseln kann, wenn der zur Verschluesselung
>verwendete Key zwischenzeitlich ueber das Verfallsdatum gekommen ist?
>Bisher kann ich darin keinen besonderen Nutzen erkennen.
Ich halte es für ein Feature.
Michael Ströder
Und ich halte es für einen Bug. IMHO sollte mit einer entsprechenden
Warnung entschlüsselt werden. Ich sehe absolut keinen Sicherheitsnutzen
darin, es nicht zu tun.
Natürlich sollte man nicht mit einem abgelaufenen Schlüssel
*verschlüsseln* können.
Ciao, Michael.
Jens v.P.
Achim Stump wrote:
> Aber mal im Ernst: Ist das ein Bug oder ein Feature, dass man Dateien
> nicht mehr entschluesseln kann, wenn der zur Verschluesselung
> verwendete Key zwischenzeitlich ueber das Verfallsdatum gekommen ist?
> Bisher kann ich darin keinen besonderen Nutzen erkennen.
Kommt vielleicht darauf an, warum überhaupt keys mit expire erstellt
werden.
Ich meine, wozu ist ein expire gut, wenn´s keinen interessiert?
Vielleicht sollte mensch noch zwischen private- und public-expire
uterscheiden können... Wo ist denn der Nutzen, einen expire key zu
machen? Die Antwort auf die Frage müßte auch obige Frage beantworten,
oder?
Cheers!
jens
_________________________________________________________________
Sorry for using an anonymous email address - I was tired of
getting spam mails... If necessary, you´ll find the address
in the mail body!
Achim Stump
Donnerhacke) wrote:
>* Achim Stump wrote:
>>Aber mal im Ernst: Ist das ein Bug oder ein Feature, dass man Dateien
>>nicht mehr entschluesseln kann, wenn der zur Verschluesselung
>>verwendete Key zwischenzeitlich ueber das Verfallsdatum gekommen ist?
>>Bisher kann ich darin keinen besonderen Nutzen erkennen.
>
>Ich halte es für ein Feature.
Mit welchem Nutzen?
Wenn es ein Feature sein sollte, dann laege aber ein Bug darin, dass
man die Entschluesselungsverweigerung durch einfaches Zurueckstellen
des Systemdatums umgehen kann. Ausserdem passt die Fehlermeldung
(private key nicht vorhanden) nicht zur Ursache (key expired).
Achim
Achim Stump
<lo...@body.for_address> wrote:
>Achim Stump wrote:
>> Aber mal im Ernst: Ist das ein Bug oder ein Feature, dass man Dateien
>> nicht mehr entschluesseln kann, wenn der zur Verschluesselung
>> verwendete Key zwischenzeitlich ueber das Verfallsdatum gekommen ist?
>Kommt vielleicht darauf an, warum ueberhaupt keys mit expire erstellt
>werden.
>Wo ist denn der Nutzen, einen expire key zu
>machen? Die Antwort auf die Frage muesste auch obige Frage beantworten,
Wenn man bei der Key-Generierung sicher weiss, dass zu einem
bestimmten Zeitpunkt die EMail-Adresse ungueltig wird, kann man mit
einem Verfallsdatum dafuer sorgen, dass spaeter nicht mehr fuer die
dann ungueltige Adresse verschluesselt wird. Aber warum der Inhaber
des Schluessels nicht mehr an die fuer ihn bestimmten Daten dran
kommen soll ist mir (bisher) in keinem Szenario einsichtig.
Michael Ströder
>
> >Kommt vielleicht darauf an, warum ueberhaupt keys mit expire erstellt
> >werden.
> >Wo ist denn der Nutzen, einen expire key zu
> >machen? Die Antwort auf die Frage muesste auch obige Frage beantworten,
>
> Wenn man bei der Key-Generierung sicher weiss, dass zu einem
> bestimmten Zeitpunkt die EMail-Adresse ungueltig wird, kann man mit
> einem Verfallsdatum dafuer sorgen, dass spaeter nicht mehr fuer die
> dann ungueltige Adresse verschluesselt wird.
Hmm, für den Fall, daß die E-Mail-Adresse ungültig wird, ist eher ein
Widerruf (Revocation) angebracht. Ein Verfallsdatum (Expire) soll, je
nach Policy, den Anwender dazu zwingen, immer neue Schlüsselpaare zu
erzeugen, da sein privater Schlüssel ja irgendwann mal unbemerkt
kompromittiert worden sein könnte.
> Aber warum der Inhaber
> des Schluessels nicht mehr an die fuer ihn bestimmten Daten dran
> kommen soll ist mir (bisher) in keinem Szenario einsichtig.
Mir auch nicht.
Ciao, Michael.
Thomas Roessler
>>Aber mal im Ernst: Ist das ein Bug oder ein Feature, dass man
>>Dateien nicht mehr entschluesseln kann, wenn der zur
>>Verschluesselung verwendete Key zwischenzeitlich ueber das
>>Verfallsdatum gekommen ist? Bisher kann ich darin keinen besonderen
>>Nutzen erkennen.
>Ich halte es für ein Feature.
Warum das? Es bringt keinen Sicherheitsgewinn, da der geheime
Schlüssel natürlich weiterhin vorhanden ist.
Und es bringt Ärger, wenn z.B. regelmäßig geänderte
Verschlüsselungsschlüssel zum Einsatz kommen, Nachrichten vor der
Archivierung aber nicht umverschlüsselt werden.
Ich denke, eine vernünftige Lösung müßte so aussehen:
- Ausgelaufene und zurückgerufene Schlüssel können weiterhin zum
Dechiffrieren von Nachrichten verwendet werden.
- Dokumentensignaturen gelten als gültig, wenn sie zu einem
Zeitpunkt erstellt wurden, zu dem der Schlüssel gültig war.
Verifizierung nach Ungültigmachung des Schlüssels führt dabei zu
einer Warnung.
- Schlüsselsignaturen sind dann und nur dann gültig, wenn der
signierende Schlüssel zum Zeitpunkt der Signatur _und_ zum
Zeitpunkt der Verifizierung gültig war.
Ausnahme: Selbstsignaturen sind gültig, sofern sie innerhalb des
Gültigkeitszeitraums des Schlüssels erstellt wurden.
Ausnahme: Zertifikatsrückrufe sind gültig, sofern sie nach dem
Erstellungszeitpunkt des Schlüssels erzeugt wurden.
- Verschlüsseln von Nachrichten an und Signieren mit ungültigen
Schlüsseln wird von der Software abgelehnt.
Ausnahme: Zertifikatsrückrufe können auch mit einem
zurückgerufenen oder ausgelaufenen Schlüssel erzeugt werden.
Ich denke, der strittigste Punkt in diesem Zusammenhang ist die
Gültigkeit von Schlüsselsignaturen. Man könnte hier das gleiche
Gültigkeitsmodell zugrundelgen wie bei Dokumentsignaturen.
Allerdings schleppen wir immer noch die Altlast der nicht
hinreichend weitgehend implementierten Zertifikatsrückrufe mit uns
herum.
(Die Gültigkeit der Zuordnung Schlüssel-User-Id habe ich dabei nur
angekratzt.)
tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
Elmar Haneke
>On Tue, 05 Jan 1999 14:25:26 +0100, Mirko Zeibig
><mirko....@picard.inka.de> wrote:
>
>>Uhr zurueckstellen ;-)?!?
>
>Jawoll! Prima workaround.
>Die einfachen Loesungen sind meist die schoensten.
>
>Aber mal im Ernst: Ist das ein Bug oder ein Feature, dass man Dateien
>nicht mehr entschluesseln kann, wenn der zur Verschluesselung
>verwendete Key zwischenzeitlich ueber das Verfallsdatum gekommen ist?
>Bisher kann ich darin keinen besonderen Nutzen erkennen.
Grundsätzlich halte ich das für Nützlich, durch das Expire bewirkt
man, daß regelmäßig die Schlüssel gewechselt werden.
Die Sicherheit des Expire schätze ich ähnlich ein, wie die "nur
lesen"-Option, die erinnert den Empfänger daran, die Nachricht nicht
unverschlüsselt abzuspeichern.
Die Möglichkeit, den Key nach einer entsprechenden Warnung dennoch zu
verwenden hoelte ich allerdings für ehrlicher, zumal das mit Tricks
immer möglich ist.
Elmar
Torsten Jerzembeck
>* Achim Stump wrote:
>>Aber mal im Ernst: Ist das ein Bug oder ein Feature, dass man Dateien
>>nicht mehr entschluesseln kann, wenn der zur Verschluesselung
>>verwendete Key zwischenzeitlich ueber das Verfallsdatum gekommen ist?
>>Bisher kann ich darin keinen besonderen Nutzen erkennen.
Auch dann, wenn Du Deine alten Mails nicht mehr lesen kannst, weil Dein
alter Key mittlerweile expired ist?
Ich halte das eher für einen Bug.
Grüße aus Münster,
=ToJe=
--
Torsten Jerzembeck * Dahlweg 49 * D-48153 Münster (Westfalen)
* PGP public key ID: B74DB58D * MIME welcome * Generation Tux *
Und das "S" in "Slackware" wird nicht mitgesprochen. (Kristian Köhntopp)
Soeren Todt
> > Daß man dieses Feature mit einer simplen Datumsverbiegung umgehen kann,
> > findich sehr eichelartich.
> Ist halt nur Software.
Waere aber eine Kleinigkeit das zu aendern. pgp merkt sich die Zeit und
legt sie verschluesselt ab. Ein Zurueck gaebe es dann nimmer. Aber
wozu?
ERROR - someone has manipulated the timer.
Press exact 103 keys and enter your pass phrase to stop deleting all
disks!
Lutz Donnerhacke
>Ich denke, eine vernünftige Lösung müßte so aussehen:
>
>- Ausgelaufene und zurückgerufene Schlüssel können weiterhin zum
> Dechiffrieren von Nachrichten verwendet werden.
Ack.
>- Dokumentensignaturen gelten als gültig, wenn sie zu einem
> Zeitpunkt erstellt wurden, zu dem der Schlüssel gültig war.
> Verifizierung nach Ungültigmachung des Schlüssels führt dabei zu
> einer Warnung.
Nack. Ungültig.
>- Schlüsselsignaturen sind dann und nur dann gültig, wenn der
> signierende Schlüssel zum Zeitpunkt der Signatur _und_ zum
> Zeitpunkt der Verifizierung gültig war.
>
> Ausnahme: Selbstsignaturen sind gültig, sofern sie innerhalb des
> Gültigkeitszeitraums des Schlüssels erstellt wurden.
>
> Ausnahme: Zertifikatsrückrufe sind gültig, sofern sie nach dem
> Erstellungszeitpunkt des Schlüssels erzeugt wurden.
;-)
>- Verschlüsseln von Nachrichten an und Signieren mit ungültigen
> Schlüsseln wird von der Software abgelehnt.
>
> Ausnahme: Zertifikatsrückrufe können auch mit einem
> zurückgerufenen oder ausgelaufenen Schlüssel erzeugt werden.
Logo.
>Ich denke, der strittigste Punkt in diesem Zusammenhang ist die
>Gültigkeit von Schlüsselsignaturen. Man könnte hier das gleiche
>Gültigkeitsmodell zugrundelgen wie bei Dokumentsignaturen.
Nein.
>Allerdings schleppen wir immer noch die Altlast der nicht
>hinreichend weitgehend implementierten Zertifikatsrückrufe mit uns
>herum.
Ack.
Michael Ströder
>
> * Thomas Roessler wrote:
> >Ich denke, eine vernünftige Lösung müßte so aussehen:
> >- Dokumentensignaturen gelten als gültig, wenn sie zu einem
> > Zeitpunkt erstellt wurden, zu dem der Schlüssel gültig war.
> > Verifizierung nach Ungültigmachung des Schlüssels führt dabei zu
> > einer Warnung.
>
> Nack. Ungültig.
"Nack" wegen fehlendem zertifizierten Timestamp?
> >Ich denke, der strittigste Punkt in diesem Zusammenhang ist die
> >Gültigkeit von Schlüsselsignaturen. Man könnte hier das gleiche
> >Gültigkeitsmodell zugrundelgen wie bei Dokumentsignaturen.
>
> Nein.
Warum "Nein"? Bei PGP's Web-Of-Trust hat man doch eine ähnlich enge
Vertrauensbeziehung zu jemanden, dem man bzgl. Schlüsselsignaturen
vertraut, wie zu jemandem, dessen Dokumentsignaturen man akzeptiert.
> >Allerdings schleppen wir immer noch die Altlast der nicht
> >hinreichend weitgehend implementierten Zertifikatsrückrufe mit uns
> >herum.
>
> Ack.
Allerdings. Das ist ein Hauptnachteil von PGP.
Ciao, Michael.
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>>
>> * Thomas Roessler wrote:
>> >Ich denke, eine vernünftige Lösung müßte so aussehen:
>> > [..]
>> >- Dokumentensignaturen gelten als gültig, wenn sie zu einem
>> > Zeitpunkt erstellt wurden, zu dem der Schlüssel gültig war.
>> > Verifizierung nach Ungültigmachung des Schlüssels führt dabei zu
>> > einer Warnung.
>>
>> Nack. Ungültig.
>
>"Nack" wegen fehlendem zertifizierten Timestamp?
Nein, wegen falscher Leseung meinerseits. Sorry.
Thomas Roessler
>> Ausserdem ist der geheime Schluessel normalerweise nicht ausspioniert
>>wenn er expired ist.
>Wir sind von einem kompromittiertem Schlüssel ausgegangen.
Und? Nur, weil ein anderer meine alten Mails lesen kann, darf ich
das selbst nicht mehr? Absurd.
>>Ist halt nur Software.
>Aber der Schlüssel könnte einen Tag erhalten, daß der Schlüssel
>endgültig ungültig wird, sobald das Datum überschritten wurde, oder?
M-x hexl-mode
Lutz Donnerhacke
>Aber das sind nur so meine oberflächlichen Gedanken. Bin kein Experte, nur
>User. Da Lutz bereits bestätigt hat, daß es ein Feature ist, bin ich wohl auf
>dem Holzweg.
Wenn Du guten Argumenten wegen mir nicht glaubst, bist Du sicher auf dem
Holzweg. Ich habe eine Fehlerquote von deutlich über 12 µH.
Thomas Roessler
>>>Wir sind von einem kompromittiertem Schlüssel ausgegangen.
>>Und? Nur, weil ein anderer meine alten Mails lesen kann, darf ich
>>das selbst nicht mehr? Absurd.
>Nein wennschon, dann IMHO keiner.
Wennschon was?
>Schlimm wird es, wenn er in Deinem Namen signiert.
Und das willst Du dadurch verhindern, daß die Software es per
Default nicht unterstützt? Faszinierend.
Michael Ströder
>
> > Erst mal richtig so? Ich kann nun aber - durch Datumsverschiebung -
> > trotzdem mit Deinem Key signieren, und eine Mail an Dich, die ich
> > abgefangen habe, entschlüsseln.
> Genau. Wenn man den Secret Key hat kann man signieren was man will.
> Davon haelt kein Expire und kein Schluesselwiderruf ab.
Doch. Expire und Schlüsselwiderruf machen einen Schlüssel beim Empfänger
ungültig. Du kannst dann zwar eine Signatur erzeugen, welche dann aber
beim Empfänger bei der (korrekten) Überprüfung als ungültig erkannt
wird.
Bleibt natürlich das Time-granularity-Problem beim
Schlüssel-/Zertifikat-Widerruf und die Frage, ob die
*Empfänger*-Software die Überprüfung richtig handhabt.
Ciao, Michael.
Soeren Todt
>
> Moin sw...@gmx.net (Soeren Todt)
> du schriebst am 08.01.99:
>
> > Waere aber eine Kleinigkeit das zu aendern. pgp merkt sich die Zeit und
> > legt sie verschluesselt ab.
Grundsaetzlich ist nichts unmoeglich.
> Nicht nur das folgende Szenarion zeigt die Unmöglichkeit. Der Keyring ist
> eine Datei und wird gesichert (alternativ alles sichern). Somit ist jede
> Änderung nach einem bestimmten Zeitpunkt auch wieder rückgängig zu machen.
> Damit ist es für PGP unmöglich zu entscheiden, ob (a) der Key noch in der
> regulären Zeit benutzt wird oder (b) die Zeit zurückgestellt wurde.
Fiktion:
PGP hat einen eingebauten eigenen Schluessel. Der wird benutzt, um
unmanipulierbar die Zeit der letzten Benutzung auf der Platte zu
sichern. Fehlt irgendwas in der Richtung, verweigert pgp seine Dienste.
Und wenn es dafuer Programmteile geben muesste, die es nur als Binary
gibt oder eine online Initalisierung voraussetzten . Aber - wer
braeuchte soawas?
--
Tippe nur in eigenem Auftrag.
Ueberschneidende Meinungen sind rein zufaellig.