Come funziona la crittografia asimmetrica a due vie?

Question

Diciamo che abbiamo Alice e Bob.

Alice invia a Bob un messaggio che ha crittografato con la chiave pubblica di Bob. Bob è l'unica persona che può decodificarlo, usando la sua chiave privata. Ma come può essere certo che il messaggio provenga da Alice?

Supponiamo che risponda, crittografando il suo messaggio utilizzando la chiave pubblica di Alice. Solo Alice può decodificare il messaggio. Ma come può essere certa che sia stata inviata da Bob?

Alice avrebbe dovuto aggiungere qualche tipo di hash pubblico al suo messaggio così Bob può dire "Questo è sicuramente venuto da Alice?"

Answer 1

Bob ha anche la chiave pubblica di Alice e Alice ha firmato il messaggio con la sua chiave privata. Bob usa la chiave pubblica di Alice per verificare la firma.

Andare al contrario per Alice per assicurarsi che il messaggio provenisse da Bob.

Tutto quello che devi fare ora è assicurarti che Bob abbia la vera chiave pubblica di Alice e non uno iniettato da un uomo nel mezzo.

Answer 2

Poiché si presuppone che una chiave privata sia realmente "privata" --i.e., Alice e bob non lasciano le chiavi USB inserite nella loro macchina quando escono dal lavoro.

Answer 3

Lo scenario che descrivi non fornisce effettivamente l'autenticità. Quindi sia Alice che Bob non possono essere sicuri che si stiano parlando. Lo scenario fornisce solo riservatezza e in quanto tale anche non segretezza.

Bob dovrebbe confermare manualmente con Alice che la chiave pubblica che pensa sia la chiave pubblica di Alice è davvero la sua (chiamandola e leggendola carica e confermando dalla sua voce che si tratta di Alice).

Questo problema viene in genere risolto con una terza parte attendibile (un'autorità di certificazione, ad esempio, come VeriSign) che emette certificati che attestano ad es. Alice è davvero il proprietario di questa particolare chiave pubblica. Questo è il modo in cui è risolto nei browser moderni e questo è il modo in cui funzionano tutte le sessioni SSL (con la tua banca di scelta). Un'autorità di certificazione firma il certificato dalla tua banca (affermando che la tua banca è effettivamente il proprietario della chiave pubblica contenuta nel certificato) e il tuo browser ha un certificato già integrato dall'autorità di certificazione (costruendo una catena di certificati che possono essere verificati).

Lo scenario che descrivi è vulnerabile a un cosiddetto attacco MITM (Man-in-the-middle) e non risolvibile puramente con crittografia a chiave pubblica.

Answer 4

Quello di cui si sta parlando assomiglia molto molto a un'altra implementazione di un Algoritmo di crittografia asimmetrico trovato nel framework .Net.

. Net utilizza due rami per la crittografia asimmetrica !!!

1. RSA ** Papà Grand Mac utilizzato per tutti gli scopi asimmetrici.
2. DSA ** più relativo all'utilizzo e alla creazione di firma digitale per verificare un autore.

Entrambi sono astratta

Entrambi sono molto simili tra loro su come funzionano e come uno sviluppatore li implementa ma sotto sotto ho letto che esistono due algoritmi molto diversi.

Si sta parlando l'opzione 2.

NET fornisce una classe chiamata DSACryptoServiceProvider che permette di contrassegnare i dati con un valore che viene comunemente indicato come firma.

Secondo un manuale scolastico ufficiale di MS, è più o meno come funziona.

>>> dati Hash Hash Alg >>> Valore >>>>>>>>> ASYMM' Alg >>>> Firma PVT.KEY mittente >>>

Qui di seguito mostra come Bob può controllare per vedere se Alice è davvero il mittente.

Dati >>> Hash Alg >>> Valore hash || Firma decifrati < < < PUB.KEY ASYMM' Alg < < < Firma < < < mittente ? ==?

Come si può vedere, Bob deve confrontare l'Hash generato e la Firma decrittografata per verificare che Alice sia il mittente. La classe DSACrypto 'ha 4 metodi che possono essere usati qui ma solo due sono efficaci dal punto di vista contestuale. A questo punto nel tempo, questo è tutto ciò che Bob può fare, se la sua chiave pubblica non è la chiave pubblica di Alice, in sostanza l'applicazione software dovrebbe impedire a Bob di continuare a procedere mentre Bob sta cercando di usare una chiave pubblica falsa quando cercando di comunicare con Alice. Questa è la relazione imposta e l'importanza sottolineata della chiave pubblica. La firma consente di verificare il proprietario delle chiavi pubbliche.

Ecco perché? ::

Se Bob ha la chiave pubblica di Alice, può utilizzare nuovamente lo stesso algoritmo per decrittografare i dati crittografati utilizzando i metodi .VerifyHash o VerifyData. Dovrebbe essere semplice ciò che fanno dato questo contesto. Questo è tutto fatto usando la chiave pubblica di Alice. Solo Alice può utilizzare i metodi SignHash e SignData poiché richiedono la chiave privata di Alice.

Come si può vedere sopra, un certo livello di funzionalità è incapsulato già nelle classi DSA e RSA CryptoServiceProvider. Si riduce a quanto bene li si implementa per verificare ogni volta che Alice è il mittente in quanto l'algoritmo DSA consente di certificare un mittente facendo corrispondere l'output generato. Una determinata firma e hash devono corrispondere, se lo fanno, in sostanza DSA ti ha concesso un certo livello di riservatezza tra Bob e Alice.