L'ID della chiave del destinatario è incluso in testo normale nel file crittografato. Altre informazioni potenzialmente interessanti "nascoste in bella vista" sono solo la dimensione del file, o il nome del file crittografato (se qualcuno lo invia senza modifiche, ovviamente).
Ciò che potresti non capire è che l'ID della chiave del destinatario è effettivamente un campo facoltativo. Sezione 5.1 continua a dire:
An implementation MAY accept or use a Key ID of zero as a "wild card" or "speculative" Key ID. In this case, the receiving implementation would try all available private keys, checking for a valid decrypted session key. This format helps reduce traffic analysis of messages.
Puoi crittografare utilizzando il flag -R (o --hidden-recipient ) con gpg per evitare di rivelare la chiave pubblica del destinatario in un messaggio crittografato.
$ gpg -e -R [email protected] message.txt
$ $ gpg --verbose --verbose --decrypt message.txt.gpg
:pubkey enc packet: version 3, algo 1, keyid 0000000000000000
data: [2047 bits]
gpg: public key is 00000000
gpg: anonymous recipient; trying secret key aaaaaaaa ...
gpg: anonymous recipient; trying secret key bbbbbbbb ...
gpg: anonymous recipient; trying secret key cccccccc ...
:encrypted data packet:
length: 76
mdc_method: 2
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: secret key not available
$
A questo punto, gpg scorre tutte le chiavi private che sta cercando di ottenere una chiave di sessione valida, in quanto non può identificare la chiave pubblica utilizzata per la crittografia. Tuttavia, vedi anche questa risposta per modi di differenziare tra i destinatari se l'autore dell'attacco ha accesso a un numero elevato di messaggi.
Una soluzione pratica - indizi secondari possono essere in vari registri. Ad esempio, un utente malintenzionato che ottiene un messaggio di questo tipo potrebbe anche essere in grado di accedere (ad esempio) a un file .bash_history con l'indirizzo del destinatario o un registro di server Web con indirizzi IP che forniscono indizi a chi ha POST o GET il file , ecc.
Secondo RFC per il formato dei messaggi OpenPGP, sezione 5.1 , ogni messaggio crittografato OpenPGP contiene a almeno un pacchetto chiave di sessione crittografata a chiave pubblica, che a sua volta contiene queste informazioni in testo semplice:
Se sono stati specificati più destinatari, saranno presenti più pacchetti chiave di sessione crittografati a chiave pubblica, uno per ciascun destinatario previsto.
Quindi, in sintesi, un utente malintenzionato può limitare l'identità del destinatario previsto sulla base di un messaggio crittografato OpenPGP.
Puoi provare questo esperimento a te stesso tentando di decodificare un file a cui non hai la chiave pubblica. Come puoi vedere, l'ID della chiave dei destinatari previsti, così come il nome dell'algoritmo e il numero di versione:
$ gpg --encrypt -r '<[email protected]>' -r '<[email protected]>' --sign message.txt
$ GNUPGHOME=/tmp/empty gpg --verbose --verbose --decrypt message.txt.gpg
:pubkey enc packet: version 3, algo 16, keyid 9759103664E69CC1
data: [2048 bits]
data: [2047 bits]
gpg: public key is 64E69CC1
:pubkey enc packet: version 3, algo 16, keyid 9478F6114164312C
data: [2048 bits]
data: [2048 bits]
gpg: public key is 4164312C
:encrypted data packet:
length: 171
mdc_method: 2
gpg: encrypted with ELG-E key, ID 4164312C
gpg: encrypted with ELG-E key, ID 64E69CC1
gpg: decryption failed: secret key not available
Questa è l'informazione di testo semplice che è disponibile. Non so se sono altre informazioni che possono essere dedotte statisticamente.
Leggi altre domande sui tag pgp