Praticamente il titolo: se Alice invia un messaggio a Bob che crittografa con la chiave pubblica di Bob, è possibile per Eve dimostrare che il testo cifrato è stato crittografato con la chiave pubblica di Bob, che il messaggio crittografato è destinato a Bob?
Aggiorna
Supponiamo che l'algoritmo sia RSA.
"Proving" dipende dal fatto che il destinatario (Bob) collabori (cioè accetta di rivelare la sua chiave privata al verificatore), e anche dal tipo di algoritmi crittografici e dettagli della chiave.
Se Bob coopera , può decrittografare il messaggio; questo potrebbe mostrare che il messaggio "ha un senso" quando viene decrittografato con la chiave privata di Bob, il che è un indizio piuttosto strong del fatto che Bob era inteso come destinatario, o almeno come destinatario a . Questo dipende da ciò che si qualifica come "sensato", naturalmente. I sistemi di crittografia più asimmetrici sono hybrid : uno scambio di chiavi asimmetrico produce una chiave specifica del messaggio condivisa tra mittente e destinatario e la chiave viene quindi utilizzata per crittografare i dati effettivi dei messaggi. Se la crittografia utilizza (come dovrebbe) un MAC per rilevare le alterazioni, allora questo può essere trasformato in una prova convincente che il il mittente ha davvero lavorato con la chiave pubblica di Bob in mente (ma dipende dagli esatti algoritmi impiegati).
Si noti che, a seconda degli algoritmi utilizzati, può essere possibile per Bob prendere un messaggio esistente e calcolare la propria coppia di chiavi in modo che il messaggio (come una sequenza di byte), quando decrittografato con la sua nuova chiave privata, decodifica su un messaggio di sua scelta. Pertanto, la crittografia asimmetrica non può, in generale, essere considerata equivalente a un reclamo di proprietà.
Se Bob non collabora , le cose possono essere complicate. Ora siamo nel modello di analisi del traffico , in cui un utente malintenzionato cerca di vedere attraverso le comunicazioni anonime. In quel modello, Bob non è un potenziale aggressore, ma una potenziale vittima. Nascondere l'identità del destinatario non è una proprietà primaria della crittografia asimmetrica e dei sistemi di scambio di chiavi. Se consideriamo la crittografia asimmetrica con RSA, la chiave taglia viene trapelata, poiché corrisponde alla dimensione del messaggio crittografato; questo può ridurre il numero di possibili destinatari.
Come caso più estremo, considera Diffie-Hellman . DH è calcolato in un dato gruppo , costituito da un modulo primario p , una dimensione del sottogruppo q ( q divide p-1 ed è normalmente primo) e un generatore di sottogruppi g ( g ha ordine q , il che significa che g q = 1 mod p ). Questi valori (i "parametri di gruppo") fanno parte della chiave pubblica di Bob. Il messaggio inizierà con un valore B = g b mod p , con un esponente scelto a caso b : quel valore è un elemento sottogruppo. Per un dato messaggio crittografato asimmetricamente, è facile guardare l'intestazione, vedere il valore B e verificare se corrisponde a un dato ( p, q, g ) DH specifica di gruppo: basta calcolare B q mod p ; per il gruppo giusto, produrrà 1 , ma (con una probabilità schiacciante) non per un gruppo distinto.
Quindi se i potenziali destinatari utilizzano Diffie-Hellman e ognuno ha generato il proprio gruppo, allora questo semplice test individuerà l'effettivo destinatario. D'altra parte, se diversi destinatari decidessero di generare le rispettive coppie di chiavi all'interno del gruppo stesso (che è consentito in DH e non presenta alcuna debolezza di sicurezza), gli estranei non essere in grado di determinare quale destinatario è quello giusto: farlo implicherebbe risolvere il Decisionalimentale-Hellman problema, che è difficile (non conosciamo alcun modo per risolvere DDH, in un normale gruppo DH, tranne attraverso Discrete Logaritmo , che è ostacolato da abbastanza p e q ).
Inoltre, l'individuazione non sta dimostrando. Chiunque può prendere una copia dei parametri del gruppo DH di Bob (fanno parte della chiave pubblica di Bob, quindi pubblica essi stessi) e generare la propria coppia di chiavi all'interno dello stesso gruppo. Pertanto, essere in grado di riconoscere il gruppo di Bob in un dato messaggio non dimostra che solo Bob potesse leggere il messaggio; il messaggio potrebbe essere pensato per qualcun altro la cui chiave funziona nello stesso gruppo.
(Avere molte chiavi nello stesso gruppo è un evento molto comune quando si usa la versione a curva ellittica di DH, perché generare la propria curva è un lavoro duro e limita strongmente l'interoperabilità.)
Ho intenzione di adottare un approccio diverso nella mia risposta qui. Dichiari: " prova che il testo cifrato è stato crittografato con la chiave pubblica di Bob " dico, come sei sicuro della sua chiave di Bob. A causa della struttura dei Public Key Server ( link ) non c'è nulla che mi impedisca di fare una chiave che finge di essere "Bob". Non esiste inoltre alcun MECCANISMO per convalidare che Bob è il periodo ultimo per i destinatari. Per esempio. Vedi qui: link
Qual è il finale finale di questa domanda? E 'quello del ripudio? Mentre mi è piaciuta la risposta di Tom Leek, la mia risposta è una " minaccia " in cui lo scopo è quello di illustrare che NON PUO in definitiva fare affidamento sulla crittografia. C'è nessun meccanismo per convalidare chi ha messo la chiave su quel server. Puoi citare in giudizio il MIT in speranze che stanno registrando, ma ottieni cosa? Un IP Questo non ha senso.
Per approfondire ulteriormente, le chiavi private possono essere compromesse con un logger di tasti, malware, ecc. In questo modo gli autori di malware che hanno "distribuzioni" mirate (Debian, FreeBSD, ecc.) sono riusciti a introdursi in frammenti di spazzatura in tutto gli anni. Gestione delle chiavi orribile.
Usando solo RSA come attualmente implementato, no, questo non è possibile. L'unico modo per Eve di provare che il messaggio è stato crittografato con la chiave pubblica di Bob è di decrittografarlo usando la chiave privata di Bob, e che sconfigge l'intero scopo della crittografia a chiave pubblica (per mantenere la chiave della coppia che dimostra che sei tu, la "chiave privata", privata).
Esistono meccanismi che consentono a qualcuno di imparare qualcosa sul messaggio senza decrittografare completamente il tutto. Prendi in considerazione uno schema in cui Alice crittografa il messaggio effettivo utilizzando la chiave pubblica di Bob, quindi accetta quel messaggio, aggiunge alcune informazioni di "intestazione" non riservate, inclusa l'origine e il destinatario previsto, quindi firma l'intero pacchetto con l'Algoritmo della firma digitale utilizzando la stessa Alice chiave privata. Chiunque conosca la chiave pubblica di Alice (e questa è un'informazione pubblica) può verificare la firma digitale, e quindi può sapere che Alice ha inviato questo messaggio esattamente come lo ha attualmente, incluse le informazioni sul destinatario previsto. Non riescono ancora a vedere il messaggio, né possono provare che il messaggio è stato effettivamente crittografato con la chiave pubblica di Bob, ma in realtà non sono affari loro; se Bob non può decifrarlo, allora può dire ad Alice che ha sbagliato.
Con un ulteriore aggiustamento per cifrare simmetricamente il messaggio reale e quindi cifrare la chiave per quel messaggio in modo asimmetrico con la chiave pubblica del destinatario, questa è l'idea di base dietro PGP. Esistono informazioni inerenti al transito e-mail che devono semplicemente essere chiaramente visibili per poter inviare l'e-mail al destinatario. Ma è importante poter dimostrare chi lo ha inviato, quali erano le loro intenzioni e che nessuno lo ha manomesso, prima di provare a leggere i contenuti effettivi.
Un altro strato di complessità dietro l'intera cosa è come dimostrare che la chiave pubblica di qualcuno è davvero la loro; ciò si realizza con la firma delle chiavi, in cui un'entità affidabile garantisce la validità delle informazioni aggiungendo informazioni che solo qualcuno che sa che la chiave privata dell'entità potrebbe produrre (una firma DSA o un hash crittografico che viene poi crittografato con la chiave privata dell'entità) ). In SSL / TLS la firma forma una "catena di fiducia" gerarchica, con una CA che garantisce il certificato di un utente finale, un'altra CA che rilascia il certificato di CA e così via, che riporta a uno dei certificati "trusted root" distribuiti con il browser Web o sistema operativo, di cui ci si deve fidare se si desidera utilizzare il sistema. In PGP è una struttura di "rete di fiducia" più piatta, in cui i pari che si conoscono e si fidano l'un l'altro firmano a vicenda le chiavi in un ambiente sicuro, quindi li distribuiscono ad altre persone che conoscono e si fidano del firmatario e quindi possono fidarsi del certificato.
Leggi altre domande sui tag encryption rsa asymmetric