info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
GnuPG Master Key und expiration
10 views
Skip to first unread message
Marc Haber
Sep 10, 2017, 6:12:34 AM9/10/17
to
Hallo,
gesetzt den Fall, ich habe einen GnuPG-Key, der ein Ablaufdatum hat.
Dieses Ablaufdatum kann ich doch, wenn ich den Private Key und die
Passphrase habe, verschieben. Kann ich das auch, wenn der Key bereits
abgelaufen _ist_?
Wie sieht es aus, wenn der Key in einer OpenPGP-Smartcard abgelegt
ist? Kann ich bei so einem Key das Ablaufdatum auch verschieben?
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
gesetzt den Fall, ich habe einen GnuPG-Key, der ein Ablaufdatum hat.
Dieses Ablaufdatum kann ich doch, wenn ich den Private Key und die
Passphrase habe, verschieben. Kann ich das auch, wenn der Key bereits
abgelaufen _ist_?
Wie sieht es aus, wenn der Key in einer OpenPGP-Smartcard abgelegt
ist? Kann ich bei so einem Key das Ablaufdatum auch verschieben?
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Thomas Hochstein
Sep 10, 2017, 2:45:02 PM9/10/17
to
Peter Faust schrieb:
> Marc Haber wrote:
>> gesetzt den Fall, ich habe einen GnuPG-Key, der ein Ablaufdatum hat.
>>
>> Dieses Ablaufdatum kann ich doch, wenn ich den Private Key und die
>> Passphrase habe, verschieben. Kann ich das auch, wenn der Key bereits
>> abgelaufen _ist_?
>
> Natürlich.
Dann ist ein Ablaufdatum nicht ausreichend, um sicherzustellen, dass
ein Key nach dessen Ablauf nicht missbraucht werden kann (wenn bspw.
aus dem Public-Key der Private-Key ermittelt werden kann)? Man müsste
ihn dementsprechend ergänzend revoken?
> Marc Haber wrote:
>> gesetzt den Fall, ich habe einen GnuPG-Key, der ein Ablaufdatum hat.
>>
>> Dieses Ablaufdatum kann ich doch, wenn ich den Private Key und die
>> Passphrase habe, verschieben. Kann ich das auch, wenn der Key bereits
>> abgelaufen _ist_?
>
Dann ist ein Ablaufdatum nicht ausreichend, um sicherzustellen, dass
ein Key nach dessen Ablauf nicht missbraucht werden kann (wenn bspw.
aus dem Public-Key der Private-Key ermittelt werden kann)? Man müsste
ihn dementsprechend ergänzend revoken?
Helmut Waitzmann
Sep 11, 2017, 8:41:22 AM9/11/17
to
Rainer Zwerschke
Sep 11, 2017, 3:13:31 PM9/11/17
to
"Thomas Hochstein" <t...@inter.net> schrieb im Newsbeitrag
news:dcsm.1709...@meneldor.ancalagon.de...
Ablaufdatum das geringste aller Probleme.
Dann bricht das ganze System zusammen!
Juergen Ilse
Sep 12, 2017, 4:52:24 AM9/12/17
to
Hallo,
Mathias Fuhrmann <yz.sh...@spamfence.net> wrote:
> Ideen haben die 'Leute'. ;-)
> Selbst wenn jemand meinen privaten Schlüssel auf anderem Wege erhält,
> kann er immer noch nicht eine E-Mail pp. damit unterschreiben. :-)
Wenn er deinen (nicht mit Passphrase gesicherten) private key erhaelt, kann
er selbstverstaendlich damit eine E-Mail in deinem Namen unterschreiben
(wenn er sie mit deiner Absender-Adresse absendet). Er koennte damit alles
tun, was auch du damit tun kannst. Das selbe gilt, falls jemand deinen mit
Passphrase geschuetzten Key in die Haende bekommt und auf irgendeine Art
deine Passphrasxe in Erfahrung bringen konnte.
> Eine (verschlüsselte oder auch nicht) Nachricht ist für mich ohne
> Unterschrift immer suspekt.
Ansender kann man faelschen, und dann mit dem Key des angeblichen Absenders
digital signieren. Deswegen ist es ja so wichtig, dass der private Schluessel
nie in fremde Haende geraet. Der public key laesst AFAIK sich aus dem pri9vate
Key wiederherstellen, umgekehrt geht es nicht (und darf es auch nicht gehen).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Mathias Fuhrmann <yz.sh...@spamfence.net> wrote:
> Ideen haben die 'Leute'. ;-)
> Selbst wenn jemand meinen privaten Schlüssel auf anderem Wege erhält,
> kann er immer noch nicht eine E-Mail pp. damit unterschreiben. :-)
Wenn er deinen (nicht mit Passphrase gesicherten) private key erhaelt, kann
er selbstverstaendlich damit eine E-Mail in deinem Namen unterschreiben
(wenn er sie mit deiner Absender-Adresse absendet). Er koennte damit alles
tun, was auch du damit tun kannst. Das selbe gilt, falls jemand deinen mit
Passphrase geschuetzten Key in die Haende bekommt und auf irgendeine Art
deine Passphrasxe in Erfahrung bringen konnte.
> Eine (verschlüsselte oder auch nicht) Nachricht ist für mich ohne
> Unterschrift immer suspekt.
Ansender kann man faelschen, und dann mit dem Key des angeblichen Absenders
digital signieren. Deswegen ist es ja so wichtig, dass der private Schluessel
nie in fremde Haende geraet. Der public key laesst AFAIK sich aus dem pri9vate
Key wiederherstellen, umgekehrt geht es nicht (und darf es auch nicht gehen).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Rainer Zwerschke
Sep 13, 2017, 6:29:25 AM9/13/17
to
"Mathias Fuhrmann" <yz.sh...@spamfence.net> schrieb im Newsbeitrag
news:op8b4j$md8$1...@news.albasani.net...
> Juergen Ilse schrieb:
>
>> Mathias Fuhrmann <yz.sh...@spamfence.net> wrote:
>>> Ideen haben die 'Leute'. ;-)
>>> Selbst wenn jemand meinen privaten Schlüssel auf anderem Wege erhält,
>>> kann er immer noch nicht eine E-Mail pp. damit unterschreiben. :-)
>
>> Wenn er deinen (nicht mit Passphrase gesicherten) private key erhaelt,
>> kann
>> er selbstverstaendlich damit eine E-Mail in deinem Namen unterschreiben
>
> Auf die ihm fehlende (sichere) Passphrase wollte ich doch hinaus. Diese
>> Mathias Fuhrmann <yz.sh...@spamfence.net> wrote:
>>> Ideen haben die 'Leute'. ;-)
>>> Selbst wenn jemand meinen privaten Schlüssel auf anderem Wege erhält,
>>> kann er immer noch nicht eine E-Mail pp. damit unterschreiben. :-)
>
>> Wenn er deinen (nicht mit Passphrase gesicherten) private key erhaelt,
>> kann
>> er selbstverstaendlich damit eine E-Mail in deinem Namen unterschreiben
>
> dürfte er mit an Sicherheit grenzender Wahrscheinlichkeit nicht haben
> und somit die Nachricht auch nicht unterschreiben können.
>
>> (wenn er sie mit deiner Absender-Adresse absendet). Er koennte damit
>> alles
>> tun, was auch du damit tun kannst. Das selbe gilt, falls jemand deinen
>> mit
>> Passphrase geschuetzten Key in die Haende bekommt und auf irgendeine Art
>> deine Passphrasxe in Erfahrung bringen konnte.
>
> Richtig, meine Passphrase liegt aber nirgendwo herum und einen
>> (wenn er sie mit deiner Absender-Adresse absendet). Er koennte damit
>> alles
>> tun, was auch du damit tun kannst. Das selbe gilt, falls jemand deinen
>> mit
>> Passphrase geschuetzten Key in die Haende bekommt und auf irgendeine Art
>> deine Passphrasxe in Erfahrung bringen konnte.
>
> PGP-Schlüssel _ohne_ gibt es meines Wissens doch gar nicht.
> Gut, bin in Sachen PGP seit ca. 20 Jahren nur Praktiker und in meinem
> Bekanntenkreis nutzt nahezu niemand PGP, aber
>
>>> Eine (verschlüsselte oder auch nicht) Nachricht ist für mich ohne
>>> Unterschrift immer suspekt.
>
> und wer das stets beherzigt (und von seinem PGP-Nutzerkreis auch
>>> Eine (verschlüsselte oder auch nicht) Nachricht ist für mich ohne
>>> Unterschrift immer suspekt.
>
> fordert), ist m.E. auf der sicheren Seite.
>
>> Ansender kann man faelschen, und dann mit dem Key des angeblichen
>> Absenders
>> digital signieren. Deswegen ist es ja so wichtig, dass der private
>> Schluessel
>> nie in fremde Haende geraet. Der public key laesst AFAIK sich aus dem
>> pri9vate
>> Key wiederherstellen, umgekehrt geht es nicht (und darf es auch nicht
>> gehen).
>
> Wer ist schon absolut sicher, daß niemand, wirklich niemand, an seinen
>> Ansender kann man faelschen, und dann mit dem Key des angeblichen
>> Absenders
>> digital signieren. Deswegen ist es ja so wichtig, dass der private
>> Schluessel
>> nie in fremde Haende geraet. Der public key laesst AFAIK sich aus dem
>> pri9vate
>> Key wiederherstellen, umgekehrt geht es nicht (und darf es auch nicht
>> gehen).
>
> Privaten Schlüssel kommt? Die Wahrscheinlichkeit, die Passphrase zu
> erhalten, ist m.E. schon extrem geringer bzw. ganz ausgeschlossen.
> Zumindest, wenn keine entsprechende Schadprogramm auf dem Rechner
> mitläuft. ;-)
>
Du weißt aber schon wie das mit den Schlüsseln so funktioniert?
Die Passphrase "aktiviert" den privaten Schlüssel nicht oder so. Der private
Schlüssel ist damit nur selbst verschlüsselt.
Je nachdem welches Verfahren Du dafür ausgewählt hast kann diese
Verschlüsselung auch (ohne Passphrase) gbrochen werden.
Und ja, mit dem privaten Schlüssel kann jeder der ihn hat alles machen was
Du damit auch kannst.
Die Passphrase kannst Du jederzeit ändern und auch ganz entfallen lassen.
Sie ist für die Funktion des Schlüssels nicht von Bedeutung.
Rainer Zwerschke
Sep 13, 2017, 8:22:53 AM9/13/17
to
news:opb3eu$lfu$1...@news.albasani.net...
> Rainer Zwerschke schrieb:
> beziehe ich mich nur auf die Praxis (ob die natürlich immer stimmt ..?).
> nicht, muß ich doch die Passphrase eingeben. Wie kann ein Fremder diese
> umgehen?
> Und wenn er eine an mich gesendete PGP-Nachricht abfängt, wie kann er
> die ohne meine Passphrase entschlüsseln?
> wichtigste Sicherheitskriterium an.
> Geändert kann sie nur werden, wenn die z.Z. Gültige bekannt ist.
>
Die Passphrase ist der "Schlüssel für Deinen privaten Schlüssel".
Das ist genauso, wie wenn Du z.B. deinen privaten Schlüssel auf einer
verschlüsselten Festplatte (USB-Stick, etc) speicherst.
Wenn Du damit eine Nachricht signieren willst mußt Du erst die Festplatte
(USB-Stick, etc) entschlüsseln um auf den Schlüssel zugreifen zu können.
Also dein Passwort / Passphrase eingeben.
Dein Programm / Front-End übernimmt für Dich hier den Teil der sicheren
Aufbewahrung und verschlüsselt Deinen privaten Schlüssel bevor es ihn
speichert. Und weil es weiß, daß dein privater Schlüssel verschlüsselt ist
fragt es für den Gebrauch die Passphrase ab.
Wahrscheinlich ist bei Dir voreingestellt, daß der private Schlüssel
generell verschlüsselt gespeichert wird. Das ist auch gut und vernünftig!
Und dann brauchst Du tatsächlich immer eine Passphrase. (Das trifft aber
erstmal nur auf Deinen Fall / das von Dir benutzte Programm zu.)
Beim Ändern der Passphrase entschlüsselst du Deinen privaten Schlüssel mit
der alten und verschlüsselst ihn mit der neuen Passphrase und speicherst ihn
dann ab (und überschreibst den alten hoffentlich). Mehr ist das nicht. Der
Schlüssel selbst bleibt unverändert.
Wenn nun Dein (verschlüsselter) privater Schlüssel in fremde Hände gelangt
ist er so gut gesichert wie die Verschlüsselung ist. Hast Du (Dein Programm
/ Front-End) ein gutes, modernes Verfahren genommen ist die
Wahrscheinlichkeit hoch, daß ihn niemand mißbrauchen kann. Hast Du eine
ältere, bekannt unsichere Verschlüsselung genommen sieht es ganz anders aus.
Bei einer (an Dich gesendeten) Nachricht ist das nochmals anders. Die
Nachricht selbst wird im Regelfall symmetrisch verschlüsselt und nur das
mitgelieferte Passwort für die symmetrische Verschlüsslung wird asymmetrisch
verschlüsselt (sog. hybriede Verschlüsselung).
Ein Angreiffer kann nun entweder die asymmetrische Verschlüsslung angreifen
um zu versuchen den Schlüssel für die symmetrische Verschlüsselung zu
extrahieren oder auch direkt die symmetrische Verschlüsselung, die Nachricht
selbst. Letzteres ist z.B. dann sinnvoll wenn er eine (sonst noch nicht
bekannte) Schwachstelle der symmetrischen Verschlüsselung kennt.
Bei Spionagesoftware auf Deinem Rechner gibt es auch verschiedene
Möglichkeiten gegen die es entsprechende unterschiedliche Schutzmaßnahmen
gibt.
Wenn allerdings Dein privater Schlüssel direkt ausgelesen wird - er liegt
wenn das Programm ihn verwendet ja unverschlüsselt im Speicher - dann
allerdings ist Polen doch verloren.
> Rainer Zwerschke schrieb:
>
>> Du weißt aber schon wie das mit den Schlüsseln so funktioniert?
>
> Die 'Theorie' für Anwender studierte ich vor längerer Zeit, jetzt
>> Du weißt aber schon wie das mit den Schlüsseln so funktioniert?
>
> beziehe ich mich nur auf die Praxis (ob die natürlich immer stimmt ..?).
>
>> Die Passphrase "aktiviert" den privaten Schlüssel nicht oder so. Der
>> private
>> Schlüssel ist damit nur selbst verschlüsselt.
>> Je nachdem welches Verfahren Du dafür ausgewählt hast kann diese
>> Verschlüsselung auch (ohne Passphrase) gbrochen werden.
>> Und ja, mit dem privaten Schlüssel kann jeder der ihn hat alles machen
>> was
>> Du damit auch kannst.
>
> Wenn ich eine Nachricht unterschreibe, ob diese verschlüsselt wird oder
>> Die Passphrase "aktiviert" den privaten Schlüssel nicht oder so. Der
>> private
>> Schlüssel ist damit nur selbst verschlüsselt.
>> Je nachdem welches Verfahren Du dafür ausgewählt hast kann diese
>> Verschlüsselung auch (ohne Passphrase) gbrochen werden.
>> Und ja, mit dem privaten Schlüssel kann jeder der ihn hat alles machen
>> was
>> Du damit auch kannst.
>
> nicht, muß ich doch die Passphrase eingeben. Wie kann ein Fremder diese
> umgehen?
> Und wenn er eine an mich gesendete PGP-Nachricht abfängt, wie kann er
> die ohne meine Passphrase entschlüsseln?
>
>> Die Passphrase kannst Du jederzeit ändern und auch ganz entfallen lassen.
>> Sie ist für die Funktion des Schlüssels nicht von Bedeutung.
>
> Das paßt nicht zu meinen Kenntnissen, ich sehe die Passphrase als das
>> Die Passphrase kannst Du jederzeit ändern und auch ganz entfallen lassen.
>> Sie ist für die Funktion des Schlüssels nicht von Bedeutung.
>
> wichtigste Sicherheitskriterium an.
> Geändert kann sie nur werden, wenn die z.Z. Gültige bekannt ist.
>
Die Passphrase ist der "Schlüssel für Deinen privaten Schlüssel".
Das ist genauso, wie wenn Du z.B. deinen privaten Schlüssel auf einer
verschlüsselten Festplatte (USB-Stick, etc) speicherst.
Wenn Du damit eine Nachricht signieren willst mußt Du erst die Festplatte
(USB-Stick, etc) entschlüsseln um auf den Schlüssel zugreifen zu können.
Also dein Passwort / Passphrase eingeben.
Dein Programm / Front-End übernimmt für Dich hier den Teil der sicheren
Aufbewahrung und verschlüsselt Deinen privaten Schlüssel bevor es ihn
speichert. Und weil es weiß, daß dein privater Schlüssel verschlüsselt ist
fragt es für den Gebrauch die Passphrase ab.
Wahrscheinlich ist bei Dir voreingestellt, daß der private Schlüssel
generell verschlüsselt gespeichert wird. Das ist auch gut und vernünftig!
Und dann brauchst Du tatsächlich immer eine Passphrase. (Das trifft aber
erstmal nur auf Deinen Fall / das von Dir benutzte Programm zu.)
Beim Ändern der Passphrase entschlüsselst du Deinen privaten Schlüssel mit
der alten und verschlüsselst ihn mit der neuen Passphrase und speicherst ihn
dann ab (und überschreibst den alten hoffentlich). Mehr ist das nicht. Der
Schlüssel selbst bleibt unverändert.
Wenn nun Dein (verschlüsselter) privater Schlüssel in fremde Hände gelangt
ist er so gut gesichert wie die Verschlüsselung ist. Hast Du (Dein Programm
/ Front-End) ein gutes, modernes Verfahren genommen ist die
Wahrscheinlichkeit hoch, daß ihn niemand mißbrauchen kann. Hast Du eine
ältere, bekannt unsichere Verschlüsselung genommen sieht es ganz anders aus.
Bei einer (an Dich gesendeten) Nachricht ist das nochmals anders. Die
Nachricht selbst wird im Regelfall symmetrisch verschlüsselt und nur das
mitgelieferte Passwort für die symmetrische Verschlüsslung wird asymmetrisch
verschlüsselt (sog. hybriede Verschlüsselung).
Ein Angreiffer kann nun entweder die asymmetrische Verschlüsslung angreifen
um zu versuchen den Schlüssel für die symmetrische Verschlüsselung zu
extrahieren oder auch direkt die symmetrische Verschlüsselung, die Nachricht
selbst. Letzteres ist z.B. dann sinnvoll wenn er eine (sonst noch nicht
bekannte) Schwachstelle der symmetrischen Verschlüsselung kennt.
Bei Spionagesoftware auf Deinem Rechner gibt es auch verschiedene
Möglichkeiten gegen die es entsprechende unterschiedliche Schutzmaßnahmen
gibt.
Wenn allerdings Dein privater Schlüssel direkt ausgelesen wird - er liegt
wenn das Programm ihn verwendet ja unverschlüsselt im Speicher - dann
allerdings ist Polen doch verloren.
Thomas Hochstein
Sep 16, 2017, 4:15:03 PM9/16/17
to
Rainer Zwerschke schrieb:
> "Thomas Hochstein" <t...@inter.net> schrieb im Newsbeitrag
> news:dcsm.1709...@meneldor.ancalagon.de...
nun Gründe, warum bestimmte Hash- oder Verschlüsselungsalgorithmen und
Schlüssel unterhalb einer bestimmten Länge nicht mehr verwendet werden
sollen. Dass MD5 und IDEA keine gute Idee mehr sind, gefährdet
allerdings mitnichten "das ganze System".
-thh
> "Thomas Hochstein" <t...@inter.net> schrieb im Newsbeitrag
> news:dcsm.1709...@meneldor.ancalagon.de...
>> Dann ist ein Ablaufdatum nicht ausreichend, um sicherzustellen, dass
>> ein Key nach dessen Ablauf nicht missbraucht werden kann (wenn bspw.
>> aus dem Public-Key der Private-Key ermittelt werden kann)? Man müsste
>> ihn dementsprechend ergänzend revoken?
>
> Wenn man aus dem Public-Key den Privat-Key ermitteln kann ist ein
> Ablaufdatum das geringste aller Probleme.
> Dann bricht das ganze System zusammen!
"Das ganze System" bricht sicherlich nicht zusammen, aber es gibt ja
>> ein Key nach dessen Ablauf nicht missbraucht werden kann (wenn bspw.
>> aus dem Public-Key der Private-Key ermittelt werden kann)? Man müsste
>> ihn dementsprechend ergänzend revoken?
>
> Wenn man aus dem Public-Key den Privat-Key ermitteln kann ist ein
> Ablaufdatum das geringste aller Probleme.
> Dann bricht das ganze System zusammen!
nun Gründe, warum bestimmte Hash- oder Verschlüsselungsalgorithmen und
Schlüssel unterhalb einer bestimmten Länge nicht mehr verwendet werden
sollen. Dass MD5 und IDEA keine gute Idee mehr sind, gefährdet
allerdings mitnichten "das ganze System".
-thh
Thomas Hochstein
Sep 16, 2017, 4:15:03 PM9/16/17
to
Helmut Waitzmann schrieb:
> Thomas Hochstein <t...@inter.net>:
Ich dachte mir bisher, es geht dabei darum, die Erzeugung eines neuen
Schlüssels nach einem bestimmten Zeitraum zu erzwingen und einen ggf.
kompromittierten Schlüssel unbrauchbar zu machen.
Aber welchen Zweck hat ein Ablaufdatum, das ich auch nach seinem
Erreichen noch ändern kann?
-thh
> Thomas Hochstein <t...@inter.net>:
>> Dann ist ein Ablaufdatum nicht ausreichend, um sicherzustellen, dass
>> ein Key nach dessen Ablauf nicht missbraucht werden kann (wenn bspw.
>> aus dem Public-Key der Private-Key ermittelt werden kann)? Man müsste
>> ihn dementsprechend ergänzend revoken?
>
> Sehe ich auch so.
Welchen Zweck hat denn dann ein Ablaufdatum überhaupt?
>> ein Key nach dessen Ablauf nicht missbraucht werden kann (wenn bspw.
>> aus dem Public-Key der Private-Key ermittelt werden kann)? Man müsste
>> ihn dementsprechend ergänzend revoken?
>
> Sehe ich auch so.
Ich dachte mir bisher, es geht dabei darum, die Erzeugung eines neuen
Schlüssels nach einem bestimmten Zeitraum zu erzwingen und einen ggf.
kompromittierten Schlüssel unbrauchbar zu machen.
Aber welchen Zweck hat ein Ablaufdatum, das ich auch nach seinem
Erreichen noch ändern kann?
-thh
Alexander Goetzenstein
Sep 16, 2017, 6:34:46 PM9/16/17
to
Hallo,
Am 16.09.2017 um 19:56 schrieb Thomas Hochstein:
> Aber welchen Zweck hat ein Ablaufdatum, das ich auch nach seinem
> Erreichen noch ändern kann?
wenn bspw. wegen Schlüssel- oder Kennwortverlust der Schlüssel nicht
mehr zurückgezogen werden kann, ist so ein Ablauf recht nützlich; stellt
sich zum Ablaufdatum heraus, dass der Schlüssel weder kompromittiert
noch sonstwie "angekratzt" ist, kann man ihn bequem verlängern und muss
nicht den aufwendigen Weg des Neuerstellens und Austausches gehen.
--
Gruß
Alex
Am 16.09.2017 um 19:56 schrieb Thomas Hochstein:
> Aber welchen Zweck hat ein Ablaufdatum, das ich auch nach seinem
> Erreichen noch ändern kann?
mehr zurückgezogen werden kann, ist so ein Ablauf recht nützlich; stellt
sich zum Ablaufdatum heraus, dass der Schlüssel weder kompromittiert
noch sonstwie "angekratzt" ist, kann man ihn bequem verlängern und muss
nicht den aufwendigen Weg des Neuerstellens und Austausches gehen.
--
Gruß
Alex
Helmut Springer
Sep 17, 2017, 4:30:13 AM9/17/17
to
Thomas Hochstein <t...@inter.net> wrote:
> Aber welchen Zweck hat ein Ablaufdatum, das ich auch nach seinem
> Erreichen noch ändern kann?
Du kannst es aendern, denn Du kannst Deinen Schluessel per
> Aber welchen Zweck hat ein Ablaufdatum, das ich auch nach seinem
> Erreichen noch ändern kann?
Definition beliebig manipuilieren.
Aber alle anderen koennen das nicht.
Das Ablaufdatum dokumentiert, kryptographisch gesichert, Deinen
Unwillen, diesen Schluessel nach Ablaufdatum weiter zu verwenden
oder zu trauen. Dritte koennen das technisch natuerlich trotzdem,
erfordert aber vorsaetzliche Ignoranz.
--
Best Regards
helmut springer panta rhei
Helmut Springer
Sep 17, 2017, 4:38:21 AM9/17/17
to
Alexander Goetzenstein <alexander_g...@web.de> wrote:
> stellt sich zum Ablaufdatum heraus, dass der Schlüssel weder
> kompromittiert noch sonstwie "angekratzt" ist, kann man ihn bequem
> verlängern und muss nicht den aufwendigen Weg des Neuerstellens
> und Austausches gehen.
Nein. Der Ersteller des Schluessels hat seine Vertrauensfrist
> stellt sich zum Ablaufdatum heraus, dass der Schlüssel weder
> kompromittiert noch sonstwie "angekratzt" ist, kann man ihn bequem
> verlängern und muss nicht den aufwendigen Weg des Neuerstellens
> und Austausches gehen.
festgelegt. Eine Aenderung dieser Vertrauensfrist kann bereits der
Ergebnis einer Kompromitierung sein bzw. ist in band fuer Dritte
nicht davon unterscheidbar.
Technische Frage: wenn man den public key eines Anderen verfiziert
und das per signatur mit dem eigenen secret key dokumentiert: wird
dabei auch das dann praesente Ablaufdatum siginiert? Zertstoert
eine Aenderung des Ablaufdatums damit derartige Signaturen?
Thomas Hochstein
Sep 17, 2017, 6:00:02 AM9/17/17
to
Alexander Goetzenstein schrieb:
Stimmt, das ist ein sinnvolles Szenario. - Danke.
Alexander Goetzenstein
Sep 17, 2017, 6:17:01 AM9/17/17
to
Hallo,
Am 17.09.2017 um 10:38 schrieb Helmut Springer:
> Der Ersteller des Schluessels hat seine Vertrauensfrist
> festgelegt.
richtig, und die ist bspw. in dem von mir skizzierten Fall nützlich.
Falls dieser (oder ein ähnlicher) Fall nicht eintritt, kann man die
Vertrauensfrist einfach und unkompliziert verlängern.
--
Gruß
Alex
Am 17.09.2017 um 10:38 schrieb Helmut Springer:
> Der Ersteller des Schluessels hat seine Vertrauensfrist
> festgelegt.
Falls dieser (oder ein ähnlicher) Fall nicht eintritt, kann man die
Vertrauensfrist einfach und unkompliziert verlängern.
--
Gruß
Alex
Marc Haber
Sep 17, 2017, 8:18:51 AM9/17/17
to
Mathias Fuhrmann <yz.sh...@spamfence.net> wrote:
>Alexander Goetzenstein schrieb:
>Wer so unbedarft mit seinem Schlüssel oder/und dem Kennwort umgeht, ist
>m.E. nicht geeignet, PGP zu nutzen.
... was den Prozentsatz der PGP geeigneten Internetnutzer nach unten
aus dem Promillebereich herausdrückt.
>Alexander Goetzenstein schrieb:
>m.E. nicht geeignet, PGP zu nutzen.
... was den Prozentsatz der PGP geeigneten Internetnutzer nach unten
aus dem Promillebereich herausdrückt.
Rainer Zwerschke
Sep 22, 2017, 2:19:49 AM9/22/17
to
Sobald man aus dem öffentlichen Schlüssel den privaten Schlüssel
"ausrechnen" könnte wäre der private Schlüssel ja nicht mehr privat.
Der "Ausrechner" kann damit entschlüsseln, signieren, was auch immer.
Nochmal, die Passphrase ist keine Aktivierung, zwei-Faktor-Authentifizierung
oder so etwas. Sie dient nur der *lokalen* sicheren Aufbewahrung des
privaten Schlüssels.
Stefan Claas
Sep 25, 2017, 10:27:03 AM9/25/17
to
On Wed, 13 Sep 2017 13:06:06 +0200, Mathias Fuhrmann wrote:
> Und wenn er eine an mich gesendete PGP-Nachricht abfängt, wie kann er
> die ohne meine Passphrase entschlüsseln?
Ich bin zwar kein Experte, jedoch kann ich mir gut vorstellen das es
> Und wenn er eine an mich gesendete PGP-Nachricht abfängt, wie kann er
> die ohne meine Passphrase entschlüsseln?
vielleicht in einigen Jahren gut möglich sein könnte das große
Organisationen einfach dein Modulus n* von deinem öffentlichen Schlüssel
faktorisieren können und somit die Frage (falls es bis dahin nicht ein
Quantum Computer resistentes GnuPG gibt) erledigt ist.
Google mal nach D-Wave Systems.
*Ich hatte mal vor langer Zeit einfach mal die RSA Challenge 155
(512bits) gemacht und bei mir dauerte das faktorisieren genau
ein Monat und ein Tag, auf mein kleinen alten Notebook. :-)
Auf der Cloud geht sowas heutzutage natürlich schneller (4 Stunden).
Grüße
Stefan
--
https://www.behance.net/futagoza
https://keybase.io/stefan_claas
Thomas Hochstein
Sep 25, 2017, 5:15:02 PM9/25/17
to
Rainer Zwerschke schrieb:
> Sobald man aus dem öffentlichen Schlüssel den privaten Schlüssel
> "ausrechnen" könnte wäre der private Schlüssel ja nicht mehr privat.
Freilich. - Und ist nicht genau dass das Problem, wenn die
Schlüssellänge zu kurz und de Chiffre nicht mehr hinreichend sicher
ist?
Oder können dann "nur" verschlüsselte Nachrichten entschlüsselt
werden?
> Der "Ausrechner" kann damit entschlüsseln, signieren, was auch immer.
Ja, eben. - Ein Grund, alte Schlüssel mit zu kurzen Schlüssellängen
gegen neue auszutauschen. Und das wiederum ein Grund, von Anfang an
eine begrenzte Gültigkeit des Keys vorzugeben.
> Nochmal, die Passphrase ist keine Aktivierung, zwei-Faktor-Authentifizierung
> oder so etwas. Sie dient nur der *lokalen* sicheren Aufbewahrung des
> privaten Schlüssels.
Das ist mir klar.
-thh
> Sobald man aus dem öffentlichen Schlüssel den privaten Schlüssel
> "ausrechnen" könnte wäre der private Schlüssel ja nicht mehr privat.
Schlüssellänge zu kurz und de Chiffre nicht mehr hinreichend sicher
ist?
Oder können dann "nur" verschlüsselte Nachrichten entschlüsselt
werden?
> Der "Ausrechner" kann damit entschlüsseln, signieren, was auch immer.
gegen neue auszutauschen. Und das wiederum ein Grund, von Anfang an
eine begrenzte Gültigkeit des Keys vorzugeben.
> Nochmal, die Passphrase ist keine Aktivierung, zwei-Faktor-Authentifizierung
> oder so etwas. Sie dient nur der *lokalen* sicheren Aufbewahrung des
> privaten Schlüssels.
-thh
Stefan Claas
Sep 25, 2017, 5:45:02 PM9/25/17
to
On 17 Sep 2017 08:38:20 GMT, Helmut Springer wrote:
> Alexander Goetzenstein <alexander_g...@web.de> wrote:
> > stellt sich zum Ablaufdatum heraus, dass der Schlüssel weder
> > kompromittiert noch sonstwie "angekratzt" ist, kann man ihn bequem
> > verlängern und muss nicht den aufwendigen Weg des Neuerstellens
> > und Austausches gehen.
>
> Nein. Der Ersteller des Schluessels hat seine Vertrauensfrist
> festgelegt. Eine Aenderung dieser Vertrauensfrist kann bereits der
> Ergebnis einer Kompromitierung sein bzw. ist in band fuer Dritte
> nicht davon unterscheidbar.
Sollte man nicht lieber daher mit einem (un)befristeten Master key
> Alexander Goetzenstein <alexander_g...@web.de> wrote:
> > stellt sich zum Ablaufdatum heraus, dass der Schlüssel weder
> > kompromittiert noch sonstwie "angekratzt" ist, kann man ihn bequem
> > verlängern und muss nicht den aufwendigen Weg des Neuerstellens
> > und Austausches gehen.
>
> Nein. Der Ersteller des Schluessels hat seine Vertrauensfrist
> festgelegt. Eine Aenderung dieser Vertrauensfrist kann bereits der
> Ergebnis einer Kompromitierung sein bzw. ist in band fuer Dritte
> nicht davon unterscheidbar.
und zusätzlichen sub keys arbeiten? Will damit sagen du erstellst
dir ein neues Schlüsselpaar, welches entweder so und so viel Jahre
gültig ist oder eben für immer und dazu sub keys die kürzer befristet
sind (einen für signieren und einen zum verschlüsseln) Sobald du
neue sub keys für dein Schlüssel erstellst werden diese auch mit deinem
Master key signiert und sind somit für deine Kommunikationspartner
ebenso validiert, nachdem sie deinen öffentlichen Schlüssel erneut
runter laden.
> Technische Frage: wenn man den public key eines Anderen verfiziert
> und das per signatur mit dem eigenen secret key dokumentiert: wird
> dabei auch das dann praesente Ablaufdatum siginiert? Zertstoert
> eine Aenderung des Ablaufdatums damit derartige Signaturen?
Helmut Waitzmann
Sep 26, 2017, 3:03:12 AM9/26/17
to
Helmut Springer <delta+...@lug-s.org>:
den Schlüssel selbst.
> wird dabei auch das dann praesente Ablaufdatum siginiert?
Nein.
> Zertstoert eine Aenderung des Ablaufdatums damit derartige
> Signaturen?
Nein.
> Technische Frage: wenn man den public key eines Anderen verfiziert
> und das per signatur mit dem eigenen secret key dokumentiert:
… dann signiert man ein User‐Id am Schlüssel eines Anderen, nicht
> und das per signatur mit dem eigenen secret key dokumentiert:
den Schlüssel selbst.
> wird dabei auch das dann praesente Ablaufdatum siginiert?
> Zertstoert eine Aenderung des Ablaufdatums damit derartige
> Signaturen?
Alexander Goetzenstein
Sep 26, 2017, 4:45:18 AM9/26/17
to
Hallo,
Am 25.09.2017 um 23:45 schrieb Stefan Claas:
> Sollte man nicht lieber daher mit einem (un)befristeten Master key
> und zusätzlichen sub keys arbeiten?
auch dieser Schlüssel kann grundsätzlich kompromittiert werden.
--
Gruß
Alex
Am 25.09.2017 um 23:45 schrieb Stefan Claas:
> Sollte man nicht lieber daher mit einem (un)befristeten Master key
> und zusätzlichen sub keys arbeiten?
--
Gruß
Alex
Stefan Claas
Sep 26, 2017, 5:35:46 AM9/26/17
to
durch Wände hindurch auslesen kann. Was ich nur sagen wollte, man
generiert einen Master Key, sperrt diesen weg und arbeitet mit sub
keys um den möglichen Schaden begrenzt zu halten.
https://alexcabal.com/creating-the-perfect-gpg-keypair/
Schade das unser Experte Hauke Laging (OpenPGP Schulungen) hier nicht
anwesend ist und mal dazu etwas sagen kann.
Grüße
Stefan
Stefan Claas
Sep 26, 2017, 5:46:59 AM9/26/17
to
nicht mehr gehen wenn man aktuellste Versionen von GnuPG benutzt die
einen Seitenkanal Angriff, dieser Art, verhindern.
http://news.softpedia.com/news/experiment-gets-encryption-key-from-computer-in-another-room-through-the-wall-500701.shtml
0 new messages