web-dev-qa-db-fra.com

Puis-je vérifier qui peut déchiffrer mon message GPG après l'avoir chiffré?

Lorsque j'envoie, disons, une excellente recette de gâteau d'entonnoir à Alice et Bob en utilisant GPG, je peux être sûr qu'ils seront tous les deux en mesure de le décrypter. Cependant, puis-je être certain, ou prouver après coup, qu'ils seront les seuls à pouvoir? *

Context: J'ai supposé que c'était facile: les messages gpg ont une liste d'ID de clé de déchiffrement possibles, que je pensais toujours être complète. Cependant, je suis tombé sur le --try-all-secrets option pour gpg lui-même et maintenant je ne suis plus sûr. Si je comprends bien les options, je peux avoir une clé capable de déchiffrer le message, mais qui ne figure pas sur la liste "publique" des destinataires. La liste `` publique '' peut avoir un identifiant de clé de zéro pour indiquer qu'il se passe quelque chose, mais il semble que ce ne soit pas toujours nécessaire. Donc, cela m'a fait réfléchir...

Question: Pourrais-je savoir (sur la base de la sortie chiffrée uniquement) si quelqu'un a modifié ma version de gpg pour ajouter secrètement Eve en tant que destinataire anonyme? Aurais-je besoin d'être l'un des destinataires pour pouvoir le dire?

Je sais que ce scénario ne se produirait probablement jamais dans la pratique, et si un attaquant était capable de remplacer votre binaire gpg ce scénario serait probablement le moindre de vos soucis, mais je suis toujours curieux.

*: En supposant bien sûr que leurs clés privées soient gardées privées, personne ne soudoie Alice pour partager la recette gagnante, etc.

encryptionpgp
20
Wander Nauta

Vous ne pouvez pas nécessairement dire qui peut déchiffrer un fichier GPG donné en le regardant, mais en supposant que personne n'a aucune connaissance en dehors de ses propres clés privées et fichier chiffré lui-même, il est possible de dire combien de personnes peuvent.

Lorsque vous cryptez un message, GPG génère une clé symétrique aléatoire, appelée "clé de session", et l'utilise pour crypter le message. Il crée ensuite un tas de copies de la clé de session et chiffre chacune sous une clé publique différente, une pour chaque destinataire. Il regroupe ensuite tous ces "paquets de clés" chiffrés avec le message chiffré en utilisant le format de conteneur OpenPGP .

L'important est que si vous ne disposez que du fichier crypté, vous devez être en mesure de décrypter au moins un de ces paquets de clés de session cryptés afin d'accéder au message.

Vous pouvez répertorier tous les paquets dans un fichier chiffré en utilisant le gpg --list-packets commande:

$ gpg --batch --list-packets myfile.gpg
:pubkey enc packet: version 3, algo 16, keyid 0000000000000000
        data: [2048 bits]
        data: [2046 bits]
gpg: anonymous recipient; trying secret key ABCDE123 ...
:pubkey enc packet: version 3, algo 16, keyid 123ABCDE0987654F
        data: [2048 bits]
        data: [2046 bits]
:encrypted data packet:
...

(Le --batch flag empêche GPG de me demander ma phrase secrète, afin qu'il ne puisse rien décrypter. Si vous exécutez un agent GPG, cela prendra plus que cela.)

Ces "paquets chiffrés par clé publique" sont des paquets de clés de session chiffrés qui ont été lus à partir du fichier. Celui avec "keyid 123ABCDE0987654F" est un destinataire normal; l'ID de la clé est un indice pour vous dire quelle clé peut être utilisée pour déchiffrer le paquet. Celui avec "keyid 0000000000000000" est un destinataire anonyme: vous ne savez pas quelle clé le déchiffrera, mais vous savez qu'il est là en attente d'être déchiffré par quelque chose . Si votre gpg a été modifié pour ajouter Eve en tant que destinataire anonyme, c'est ce que vous verrez lors de l'inspection du fichier .gpg à l'aide d'un binaire gpg propre. C'est aussi ce que vous verriez si vous ajoutiez exprès un destinataire anonyme.

Si Eve est un peu plus intelligente, il existe plusieurs façons de masquer davantage les destinataires:

  • La valeur keyid indiquée peut être un mensonge. Le keyid tout-zéros est juste une convention, et le keyid normal n'est qu'un indice: il pourrait y avoir n'importe quoi. Eve pourrait étiqueter son paquet de clés cryptées à l'aide de l'identifiant de Bob et remplacer le paquet légitime de Bob par le sien. Cela ressemblerait à un paquet pour Bob, mais s'il essayait de l'utiliser, le déchiffrement échouerait. Seul Bob pourrait vérifier cela. Le --try-all-secrets flag est quelque peu lié, et pourrait être utile si le keyid était accidentellement incorrect.
  • Eve n'a pas besoin de mettre son paquet de clés dans le fichier, ni même de créer un paquet de clés crypté pour elle-même. Essayez le --show-session-key et --override-session-key drapeaux sur un fichier factice sans données sensibles. Ceux-ci vous permettront de gérer la clé de session directement au lieu de la cacher dans des paquets de clés chiffrés. Si Eve a remplacé votre binaire gpg, elle pourrait (par exemple) lui envoyer par e-mail la clé de session de chaque fichier que vous cryptez, ainsi qu'un hachage des données cryptées pour une identification facile. Cela viole l'hypothèse "aucune connaissance préalable" de tout à l'heure, mais j'ai senti que l'existence de ces drapeaux méritait d'être mentionnée.
26
Jander

Essaye ça:

 # gpg -d votre_fichier_encrypté> /dev/null[.____. diplomatique.____. E5Egpg: chiffré avec la clé ELG à 2048 bits, ID 245AC23E80C4A478, créé le 2005-12-17] 
 "Bobby - [email protected]" 
 Gpg: chiffré avec une clé RSA 4096 bits, ID CB6D005B993F02AB, créé le 2020-04-08 
 "Mary - [email protected]" 
 gpg: chiffré avec une clé RSA 4096 bits, ID 8AB5B9CEB6F0B2D2, créé le 2018-11-29 
 "Betty Liu - [email protected]"

(L'indicateur -d sert à déchiffrer le fichier. Au fur et à mesure que GPG déchiffre, il envoie les informations pour chaque clé à STDERR, qui s'affichera sur votre écran. Pour un déchiffrement normal, vous redirigeriez STDOUT vers un fichier mais, dans ce cas, nous ne nous soucions pas vraiment du contenu du fichier, nous le redirigeons donc vers/dev/null.)

0
AFC