GPG: Allgemeine Frage zur Entschlüsselung von anderen

Seagull69

New Member
Hallo miteinander,

Ich habe heute mal etwas angefangen zu lernen über Verschlüsselung mit gpg, habe das hier genommen : https://medium.com/@GalarnykMichael/public-key-asymmetric-cryptography-using-gpg-5a8d914c9bca

Soweit verstehe ich das, nur wenn jetzt ein anderer meine Datei entschlüsseln will... Braucht er doch meinen private key, richtig? Dort steht ja beim Schritt "Private Key Holder", dass er einfach das Passwort eingeben muss. Das hat bei mir aber auch nicht funktioniert, irgendeine Meldung dass er den key nicht findet oder so kam, bin jetzt am Handy...

Hab dann meinen private key exportiert und beim 2. Linux Server importiert. Das entschlüsseln hat dann geklappt.

Nun die Frage, war das der richtige Weg ? Macht man das so ?
 
Zum Entschlüsseln braucht man immer den Private Key (und wenn dieser mit Passwort versehen ist, auch das entsprechende Passwort).

Für das Verschlüsseln braucht man nur den Public Key.
 
Der Private Key entschlüsselt. Würde man damit "verschlüsseln" meint man wohl eher das Signieren.
Wie schon der Name sagt, die Verschlüsselung ist asymmetrisch.
 
ok danke. ich habe jetzt ein sh-Script geschrieben, was etwas verschlüsselt :

Code:
tar -czf archiv.tar.gz test.txt
gpg -e -r user archiv.tar.gz

in der Shell erhalte ich jetzt aber diesen "Fehler". aber es funktioniert dennoch :

Code:
Cannot open your terminal '/dev/pts/3' - please check.

wie kann ich das beheben ? Oder soll ich es einfach ignorieren?
 
nein. mit > dev/null gehts jetzt . Jetzt habe ich aber immer noch 2 Fragen:

1. wieso muss ich eigentlich nur nach dem 1. Entschlüsseln das Passwort eingeben ? dananch klappt es immer ohne.
2. Ein Key ist 2 Jahre gültig, was passiert dann? oder ist das nur der Zeitraum, wie lange der key in der trustdb vertrauenswürdig ist? ändere ich die Zeit mit "expire" auf z.B. 1 Woche, steht bei "gpg --list-keys" bei der zeile "pub", dass er in 1 Woche verfällt. der "sub" Key aber immer noch in 2 Jahren. versteh ich nicht.
 

Attachments

  • 2020-03-05_10.07.19.png
    2020-03-05_10.07.19.png
    21.5 KB · Views: 180
  • 2020-03-05_10.07.33.png
    2020-03-05_10.07.33.png
    30.8 KB · Views: 175
Last edited:
1. wieso muss ich eigentlich nur nach dem 1. Entschlüsseln das Passwort eingeben ? dananch klappt es immer ohne.
Weil auf deinem PC das Passwort eine gewisse Zeit gecacht wird.

2. Ein Key ist 2 Jahre gültig, was passiert dann? oder ist das nur der Zeitraum, wie lange der key in der trustdb vertrauenswürdig ist? ändere ich die Zeit mit "expire" auf z.B. 1 Woche, steht bei "gpg --list-keys" bei der zeile "pub", dass er in 1 Woche verfällt. der "sub" Key aber immer noch in 2 Jahren.
Wenn ein Schlüssel abläuft, dann kannst du ihn nicht mehr zum Signieren uns/oder Verschlüsseln (oder was du sonst damit machen willst, je nachdem welches Flag für die Verwendung) verwenden und beim Empfänger ist er ja auch genauso zum Prüfen unverwendbar.
 
ändere ich die Zeit mit "expire"
Ich nehme an, du benuztest dafür gpg --edit-key ...
Ohne Anwahl des keys wird immer der zuoberst angezeigte genommen.
Du musst den Schlüssel, bei dem du das Ablaufdatum ändern willst, mit key auswählen.
 
also der private key läuft immer nach 2 Jahren ab, das kann man nicht ändern, und dann lässt sich nichts mehr verschlüsseln nach dieser Zeit. mit expire in "gpg --edit-key X" kann man den Ablauf vom public Key ändern.

richtig ?
 
Richtig. Man kann sogar nach dem Ablauf die Ablaufzeit ändern.
Wenn man aber etwas verschlüsseln will und der Schlüssel ist abgelaufen, weigert sich die Software das zu verschlüsseln.

Es gibt unterschiedliche Szenarien:
  • Signatur
    Sicherstellung, dass der Inhalt nicht modifiziert worden ist und von dem Versender stammt.
    • Der Inhalt der Nachricht/Datei wird zur Generierung eines Hashwertes verwendet
    • Die Signatur wird mit dem privaten Schlüssel erstellt
      In Wirklichkeit wird der Hashwert mit dem privaten Schlüssel verschlüsselt.
    • Zwecks Überprüfung der Signatur wird der Hashwert der Nachricht/Datei gebildet.
      Die Signatur wird mit dem öffentlichen Schlüssel in einen zweiten Hashwert zurückgeführt.
      Die beiden Hashwerte werden dann vergleichen. Wenn beide stimmen, wurde der Inhalt der
      Nachricht nicht verändert und stammt von demjenigen, der den privaten Schlüssel hat.
  • Verschlüsselung
    • Der Inhalt wird mit dem öffentlichen Schlüssel verschlüsselt (jeder kann das).
      GPG wählt zufällig einen Schlüssel für die symmetrische Verschlüsselung, mit der der Inhalt verschlüsselt wird.
      Der zufällig gewählte Schlüssel wird mit dem öffentlichen Schlüssel asymmetrisch verschlüsselt.
    • Der Empfänger entschlüsselt den Inhalt (Schlüssel) mit seinem privaten Schlüssel.
      Der entschlüsselte Key wird dann zur symmetrischen Entschlüsselung des Inhalts verwendet.
    • Der Inhalt ist nicht vor Veränderung geschützt.
    • Es ist nicht sicher gestellt, dass die Nachricht vom Versender stammt.
  • Verschlüsselung/Signatur
    • Kombination aus beiden Methoden.
    • Für das Signieren wird der private Schlüssel vom Versender genutzt.
    • Für das Verschlüsseln wird der öffentliche Schlüssel des Empfängers genutzt.
    • Der Empfänger entschlüsselt die Nachricht mit seinem privaten Schlüssel und überprüft die Signatur mit dem öffentlichen Schlüssel des Versenders
GPG verwendet standardmäßig eine hybride Verschlüsselung.
 
Last edited by a moderator:
Schau mal:
Code:
test@localhorst:~ $ gpg -k a@
pub   rsa4096/0x9DC47657A1237293 2020-03-05 [SC] [verfällt: 2022-03-05]
  Schl.-Fingerabdruck = C0CA 1CBD 87D3 2D81 F82E  11F4 9DC4 7657 A123 7293
uid                [ ultimativ ] A. <a@local>
sub   rsa4096/0xB492A6B57BF21EC0 2020-03-05 [E] [verfällt: 2022-03-05]


test@localhorst:~ $ gpg -K a@
sec   rsa4096/0x9DC47657A1237293 2020-03-05 [SC] [verfällt: 2022-03-05]
  Schl.-Fingerabdruck = C0CA 1CBD 87D3 2D81 F82E  11F4 9DC4 7657 A123 7293
uid                [ ultimativ ] A. <a@local>
ssb   rsa4096/0xB492A6B57BF21EC0 2020-03-05 [E] [verfällt: 2022-03-05]


test@localhorst:~ $ gpg --edit-key a@
gpg (GnuPG) 2.2.19; Copyright (C) 2019 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Geheimer Schlüssel ist vorhanden.

sec  rsa4096/0x9DC47657A1237293
     erzeugt: 2020-03-05  verfällt: 2022-03-05  Nutzung: SC
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa4096/0xB492A6B57BF21EC0
     erzeugt: 2020-03-05  verfällt: 2022-03-05  Nutzung: E
[ ultimativ ] (1). A. <a@local>

gpg> key

sec  rsa4096/0x9DC47657A1237293
     erzeugt: 2020-03-05  verfällt: 2022-03-05  Nutzung: SC
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa4096/0xB492A6B57BF21EC0
     erzeugt: 2020-03-05  verfällt: 2022-03-05  Nutzung: E
[ ultimativ ] (1). A. <a@local>

gpg> key 0xB492A6B57BF21EC0

sec  rsa4096/0x9DC47657A1237293
     erzeugt: 2020-03-05  verfällt: 2022-03-05  Nutzung: SC
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb* rsa4096/0xB492A6B57BF21EC0
     erzeugt: 2020-03-05  verfällt: 2022-03-05  Nutzung: E
[ ultimativ ] (1). A. <a@local>

gpg> expire
Ändern des Verfallsdatums des Unterschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1
Key verfällt am 03/06/20 14:11:25 Mitteleuropõische Zeit
Ist dies richtig? (j/N) j

sec  rsa4096/0x9DC47657A1237293
     erzeugt: 2020-03-05  verfällt: 2022-03-05  Nutzung: SC
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb* rsa4096/0xB492A6B57BF21EC0
     erzeugt: 2020-03-05  verfällt: 2020-03-06  Nutzung: E
[ ultimativ ] (1). A. <a@local>

gpg> key

sec  rsa4096/0x9DC47657A1237293
     erzeugt: 2020-03-05  verfällt: 2022-03-05  Nutzung: SC
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa4096/0xB492A6B57BF21EC0
     erzeugt: 2020-03-05  verfällt: 2020-03-06  Nutzung: E
[ ultimativ ] (1). A. <a@local>

gpg> expire
Ändern des Verfallsdatums des Hauptschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
      <n>  = Schlüssel verfällt nach n Tagen
      <n>w = Schlüssel verfällt nach n Wochen
      <n>m = Schlüssel verfällt nach n Monaten
      <n>y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1
Key verfällt am 03/06/20 14:12:15 Mitteleuropõische Zeit
Ist dies richtig? (j/N) j

sec  rsa4096/0x9DC47657A1237293
     erzeugt: 2020-03-05  verfällt: 2020-03-06  Nutzung: SC
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa4096/0xB492A6B57BF21EC0
     erzeugt: 2020-03-05  verfällt: 2020-03-06  Nutzung: E
[ ultimativ ] (1). A. <a@local>

gpg: WARNUNG: Ihr Unterschlüssel zum Verschlüsseln wird bald verfallen.
gpg: Bitte erwägen Sie, dessen Verfallsdatum auch zu ändern.

gpg> list

sec  rsa4096/0x9DC47657A1237293
     erzeugt: 2020-03-05  verfällt: 2020-03-06  Nutzung: SC
     Vertrauen: ultimativ     Gültigkeit: ultimativ
ssb  rsa4096/0xB492A6B57BF21EC0
     erzeugt: 2020-03-05  verfällt: 2020-03-06  Nutzung: E
[ ultimativ ] (1). A. <a@local>
 
danke @DeaD_EyE . aber mit diesem Befehl verschlüssel ich nur, keine Signatur, richtig?

Code:
gpg -e -r tester DATEI.txt

aber was jetzt, dachte den private key kann man nicht verlängern ? :D

denn, @GwenDragon interessant, ist also doch möglich ? kann ich also beide keys auf endlos setzen damit ich mir keine Sorgen machen muss ?

ich mache jetzt mal 1 Tag und teste einfach morgen.

aber nochmal die Frage: verschlüsseln ist nach Ablauf möglich, aber beim entschlüsseln warnt mich GPG / blockiert GPG das entschlüsseln, ja?
 
Back
Top