Come posso crittografare un file usando gpg senza includere l'ID della chiave del destinatario?

Utilizza il flag -R (o --hidden-recipient ) in gpg per farlo. Maggiori dettagli in questa risposta.

Esistono diverse opzioni in gpg. Nota che puoi usare tutto questo nel tuo file gpg.conf per impostarli permanentemente (omettendo il '-' davanti alle opzioni lunghe, ma nota che --try-secret-key è un'opzione disponibile solo nella versione 2.1beta1 +, che è in beta da 3 anni a questa parte. La documentazione è stata generata per errore, credo che la maggior parte delle persone non abbia questa opzione disponibile):

--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.

Sul lato ricevente ... Nota che può essere particolarmente fastidioso se hai molte chiavi private perché gpg ti chiederà la passphrase per ognuna finché non ne trovi una funzionante. Per scorrere velocemente i prompt, premi semplicemente invio per i tasti sbagliati, gpg non dovrebbe richiedere più di una volta per tasto come questo.

Esistono diverse tecniche per la ricezione di software (come i client di posta) per alleviare questo problema. La cosa più pratica che conosco è generare un portachiavi temporaneo con le chiavi che si prevede siano i destinatari anonimi (ad esempio l'indirizzo di posta elettronica su cui hai ricevuto la posta). In caso di fallimento con quelle / quelle chiavi, gpg dovrebbe essere chiamato di nuovo senza cambiare i portachiavi per provare tutte le chiavi segrete degli utenti. I comandi sono come:

gpg --export-secret-keys <key(s)> > tmp_keyring
gpg --decrypt --no-default-keyring --secret-keyring tmp_keyring <...>
On failure:
gpg --decrypt <...>

Ecco le opzioni:

--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.

Se sei interessato alla privacy, un'altra opzione potrebbe interessarti. È letteralmente inutile e decisamente negativo per la tua privacy emettere la tua versione del sistema operativo e del software quando si inviano email:

   --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.

Per una panoramica generale delle migliori pratiche di gpg per la sicurezza e la privacy, consulta questo primer di riseup lab .

Non sono sicuro che tu possa eliminare quelle informazioni con un particolare programma, ma non vedo perché causerebbe problemi. Per quanto riguarda il funzionamento, il destinatario può firmare una nuova chiave pubblica con la propria chiave privata, crittografare la nuova chiave pubblica con la chiave pubblica del mittente, inviare la nuova chiave pubblica al mittente che il mittente potrebbe utilizzare per la trasmissione. In questo modo, la nuova chiave pubblica di "sessione" non verrà mai rivelata al mondo e non ci sarebbe alcun modo di ricollegarla al destinatario.

Vale la pena notare che è ancora possibile per qualcuno sapere che il destinatario ha parlato con il mittente, quindi se si sta tentando di impedire a chiunque di sapere che metà della conversazione è in corso, ciò non funzionerebbe.

Per risolvere il problema, il destinatario potrebbe preparare una nuova chiave pubblica (magari utilizzando date di scadenza molto brevi) e fare in modo che il file venga crittografato con questo. Pertanto, anche se sarà ancora possibile determinare per quale chiave il file è crittografato, quella chiave è nuova e quindi non associata a nessuno.