Wie bestimmt GPG intern, mit welchem/welchen Schlüssel(n) versucht werden soll, einen gegebenen Eingabeverschlüsselungs-Blob zu entschlüsseln?

Question

Ich habe in letzter Zeit mit GPG gekämpft und habe es gerade (endlich!) zum Laufen gebracht. Ich kann jetzt einen verschlüsselten Blob in gpg.exe eingeben und es gibt die Klartextversion aus, vorausgesetzt natürlich, dass es sich um einen gültigen Verschlüsselungs-Blob handelt, d. h., sein Entschlüsselungsschlüssel befindet sich in meiner Liste der privaten Schlüssel/„Krypto-Identitäten“.

Meine Frage ist: Wie genau bestimmt GPG, welcher dieser Schlüssel ausprobiert werden soll? Ist diese Information irgendwie in den Verschlüsselungs-Blob eingebrannt? Oder probiert es sie einfach blind nacheinander aus, bis einer sie erfolgreich entschlüsselt?

Es wäre schön, endlich eine Antwort auf diese Frage zu bekommen, denn ich stelle sie mir schon seit Ewigkeiten. Es fühlt sich so „primitiv“ und „Low-Tech“ an, sie alle einfach so durchzugehen. Vor allem, wenn ich beispielsweise anfange, einen Dienst zu hosten, bei dem die privaten Schlüssel von Tausenden von Personen durchgesehen werden müssen, um zu sehen, ob eine neue eingehende Nachricht mit einem davon übereinstimmt. Es scheint einfach nicht „skalierbar“ zu sein.

Ich hoffe wirklich, dass der verschlüsselte Text etwas enthält, das GPG einen Hinweis darauf gibt, welchen Schlüssel es ausprobieren soll! Ist das der Fall?

Answer 1

Das resultierende OpenPGP-Paket enthält tatsächlich dieVerschlüsselungsunterschlüssel-IDdes Empfängers, der es entschlüsseln können soll. Zum Beispiel:

$ date | gpg --encrypt | pgpdump
Old: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes)
    New version(3)
    Key ID - 0xCE7B0F19551034EF
    Pub alg - RSA Encrypt or Sign(pub 1)
    ...
New: Symmetrically Encrypted and MDC Packet(tag 18)(83 bytes)
    ...

Wenn es mehrere Empfänger gibt, gibt es mehrere „Sitzungsschlüssel“-Pakete – eines für jeden Empfänger –, die alle unterschiedlich verschlüsselte Versionen desselben symmetrischen Schlüssels enthalten.

(Ich glaube, in der nächsten Version der Spezifikation, v5, sind stattdessen vollständige Unterschlüssel-Fingerabdrücke vorgesehen. In dieser Situation reichen jedoch die gekürzten Schlüssel-IDs aus.)

---

Allerdings verfügt GnuPG über eine Option namens --throw-keyids, die dafür sorgt, dass alle Sitzungsschlüsselpakete dieselbe Schlüssel-ID 0x0000000000000000 haben. Wenn das passiert, versucht der Empfänger tatsächlich, das Paket mit roher Gewalt zu entschlüsseln, indem er alle geheimen, verschlüsselungsfähigen Unterschlüssel verwendet, die er hat.

Es gibt auch eine --hidden-recipientOption, mit der Sie einzelne Empfänger auf die gleiche Weise verbergen können, sodass Sie in der resultierenden Nachricht eine Mischung aus Null- und Nicht-Null-Schlüssel-IDs haben können. Dies kann für die Implementierung von Bcc:Kopien in E-Mail-Clients nützlich sein.

Beide Optionen können verwendet werden, wenn Sie Nachrichten über etwas wie ein öffentliches Schwarzes Brett, eine Dropbox oder ein Subreddit austauschen müssen und den beabsichtigten Empfänger nicht preisgeben möchten.

$ date | gpg -e --recipient Alice --hidden-recipient Robert | gpg --list-packets
gpg: anonymous recipient; trying secret key CE7B0F19551034EF ...
gpg: anonymous recipient; trying secret key DCDBB36BD91759A3 ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with 4096-bit RSA key, ID CE7B0F19551034EF, created 2009-10-31
gpg: encrypted with RSA key, ID 0000000000000000
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid 0000000000000000
    data: [4095 bits]
# off=527 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid CE7B0F19551034EF
    data: [4092 bits]
# off=1054 ctb=d2 tag=18 hlen=2 plen=80 new-ctb
:encrypted data packet:
...