Comment puis-je crypter un fichier à l'aide de gpg sans inclure l'ID de clé du destinataire?
Un fichier chiffré OpenPGP comprendra l'ID de clé de la clé de chiffrement publique du destinataire prévu, comme expliqué dans cette question .
Existe-t-il un moyen de supprimer ces informations du fichier chiffré résultant? gpg fournit-il une option pour ne pas inclure ces informations?
Sinon, quelles solutions de contournement sont recommandées? Je souhaite crypter un fichier pour un destinataire spécifique et le partager avec un tiers sans révéler l'identité du destinataire ou de l'expéditeur.
(On peut supposer que la clé publique du destinataire est largement partagée et associée à l'identité réelle du destinataire.)
Utilisez le -R (ou --hidden-recipient) dans gpg pour ce faire. Plus de détails dans cette réponse.
Plusieurs options existent dans gpg. Notez que vous pouvez utiliser tous ces éléments dans votre fichier gpg.conf pour les définir de manière permanente (en omettant le '-' devant les options longues, mais notez que --try-secret-key est une option uniquement disponible en version 2.1beta1 +, qui est en version bêta depuis 3 ans maintenant. La documentation a été générée par erreur, je pense que la plupart des gens n'auront pas cette option disponible):
--hidden-recipient name
-R Encrypt for user ID name, but hide the key ID of this user's key. This option
helps to hide the receiver of the message and is a limited countermeasure
against traffic analysis. If this option or --recipient is not specified,
GnuPG asks for the user ID unless --default-recipient is given.
--hidden-encrypt-to name
Same as --hidden-recipient but this one is intended for use in the options file
and may be used with your own user-id as a hidden "encrypt-to-self". These
keys are only used when there are other recipients given either by use of
--recipient or by the asked user id. No trust checking is performed for these user
ids and even disabled keys can be used.
--throw-keyids
--no-throw-keyids
Do not put the recipient key IDs into encrypted messages. This helps to hide the
receivers of the message and is a limited countermeasure against traffic analysis.
([Using a little social engineering anyone who is able to decrypt the message can
check whether one of the other recipients is the one he suspects.]) On the
receiving side, it may slow down the decryption process because all
available secret keys must be tried. --no-throw-keyids disables this option. This
option is essentially the same as using --hidden-recipient for all recipients.
Du côté de la réception ... Notez que cela peut être particulièrement ennuyeux si vous avez plusieurs clés privées car gpg vous demandera votre phrase secrète pour chacune jusqu'à ce qu'une clé de travail soit trouvée. Pour parcourir rapidement les invites, appuyez simplement sur Entrée pour les mauvaises touches, gpg ne devrait pas vous inviter plus d'une fois par touche comme ceci.
Il existe un certain nombre de techniques possibles pour recevoir des logiciels (comme les clients de messagerie) pour atténuer ce problème. Le plus pratique que je connaisse est de générer un trousseau de clés temporaire avec la ou les clés censées être le destinataire anonyme (par exemple, l'adresse e-mail sur laquelle vous avez reçu le courrier). En cas d'échec avec cette/ces clés, gpg doit être appelé à nouveau sans changer les porte-clés afin d'essayer toutes les clés secrètes des utilisateurs. Les commandes sont les suivantes:
gpg --export-secret-keys <key(s)> > tmp_keyring
gpg --decrypt --no-default-keyring --secret-keyring tmp_keyring <...>
On failure:
gpg --decrypt <...>
Voici les options:
--try-secret-key name
For hidden recipients GPG needs to know the keys to use for trial decryption.
The key set with --default-key is always tried first, but this is often not
sufficient. This option allows to set more keys to be used for trial
decryption. Although any valid user-id specification may be used for name it makes
sense to use at least the long keyid to avoid ambiguities. Note that gpg-agent
might pop up a pinentry for a lot keys to do the trial decryption. If you want
to stop all further trial decryption you may use close-window button instead
of the cancel button.
--try-all-secrets
Don't look at the key ID as stored in the message but try all secret keys in turn
to find the right decryption key. This option forces the behaviour as used by
anonymous recipients (created by using --throw-keyids or --hidden-recipient)
and might come handy in case where an encrypted message contains a bogus key ID.
--skip-hidden-recipients
--no-skip-hidden-recipients
During decryption skip all anonymous recipients. This option helps in the case that
people use the hidden recipients feature to hide there own encrypt-to key from
others. If oneself has many secret keys this may lead to a major annoyance
because all keys are tried in turn to decrypt something which was not really
intended for it. The drawback of this option is that it is currently not possible
to decrypt a message which includes real anonymous recipients.
Si vous êtes intéressé par la confidentialité, une autre option pourrait vous intéresser. Il est littéralement inutile et carrément mauvais pour votre vie privée d'émettre votre système d'exploitation et la version du logiciel lors de l'envoi d'e-mails:
--emit-version
--no-emit-version
Force inclusion of the version string in ASCII armored output. If given once only
the name of the program and the major number is emitted (default), given twice
the minor is also emitted, given triple the micro is added, and given quad an
operating system identification is also emitted. --no-emit-version disables
the version line.
Pour un aperçu général des meilleures pratiques gpg en matière de sécurité et de confidentialité, consultez cette introduction par riseup labs .
Je ne sais pas si vous pouvez supprimer ces informations avec un programme particulier, mais je ne vois pas pourquoi cela causerait des problèmes. En ce qui concerne une solution de contournement, le destinataire pourrait signer une nouvelle clé publique avec sa clé privée, crypter la nouvelle clé publique avec la clé publique de l'expéditeur, envoyer la nouvelle clé publique à l'expéditeur que l'expéditeur pourrait ensuite utiliser pour la transmission. De cette façon, la nouvelle clé publique de "session" n'est jamais révélée au monde et il n'y aurait aucun moyen de la relier au destinataire.
Il convient de noter qu'il est toujours possible pour quelqu'un de savoir que le destinataire a parlé à l'expéditeur, donc si vous essayez d'empêcher quelqu'un de connaître la moitié de la conversation, même si cela se produit, cela ne fonctionnera pas.
Comme solution de contournement, le destinataire pourrait préparer une nouvelle clé publique (en utilisant peut-être des dates d'expiration très courtes) et faire chiffrer ce fichier avec celle-ci. Ainsi, même s'il sera toujours possible de déterminer pour quelle clé le fichier est chiffré, cette clé est nouvelle et n'est donc associée à personne.