it-swarm.dev

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

Un file crittografato OpenPGP includerà l'ID chiave della chiave di crittografia pubblica del destinatario previsto, come spiegato in questa domanda .

Esiste un modo per rimuovere tali informazioni dal file crittografato risultante? gpg fornisce un'opzione per non includere tali informazioni?

In caso contrario, quali soluzioni alternative sono consigliate? Voglio crittografare un file per un destinatario specifico e condividerlo con terze parti senza rivelare l'identità del destinatario o del mittente.

(Si può presumere che la chiave pubblica del destinatario sia ampiamente condivisa e associata all'identità reale del destinatario.)

31
Flimm

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

33
kbs

Esistono diverse opzioni in gpg. Nota che puoi usare tutti questi nel tuo file gpg.conf per impostarli in modo permanente (premendo '-' davanti alle opzioni lunghe, ma nota che --try-secret-key è un'opzione disponibile solo nella versione 2.1beta1 +, che è in versione beta da 3 anni. La documentazione è stata generata per errore, penso che la maggior parte delle persone non avrà 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 tua passphrase per ognuna finché non ne verrà trovata una funzionante. Per scorrere velocemente le istruzioni, basta premere invio per i tasti sbagliati, gpg non dovrebbe chiederti più di una volta per tasto come questo.

Esistono diverse tecniche per ricevere software (come client di posta) per alleviare questo problema. Il più pratico che conosco è generare un portachiavi temporaneo con le chiavi che dovrebbero essere il destinatario anonimo (ad es. L'indirizzo e-mail su cui hai ricevuto la posta). In caso di fallimento con quella/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 assolutamente dannoso per la tua privacy emettere il tuo sistema operativo e la versione del software quando invii e-mail:

   --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, dai un'occhiata a questo primer di riseup lab .

18
user9651

Non sono sicuro se è possibile rimuovere tali informazioni con un determinato programma, ma non vedo perché causerebbe problemi. Per quanto riguarda una soluzione, il destinatario potrebbe 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 quindi utilizzare per la trasmissione. In questo modo, la nuova chiave pubblica di "sessione" non viene mai rivelata al mondo e non ci sarebbe modo di ricollegarla al destinatario.

Vale la pena notare che è ancora possibile che qualcuno sappia che il destinatario ha parlato con il mittente, quindi se stai cercando di impedire a qualcuno di sapere se si sta verificando la metà di una conversazione, ciò non funzionerebbe.

3
AJ Henderson

Per ovviare al problema, il destinatario potrebbe preparare una nuova chiave pubblica (magari utilizzando date di scadenza molto brevi) e far sì che quel file sia crittografato con questo. Quindi, anche se sarà ancora possibile determinare per quale chiave il file è crittografato, quella chiave è nuova e quindi non associata a nessuno.

1