Loading
Study Reminders
Support
Text Version

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Fondamenti della crittografia Prof. Dr. Ashish Choudhury Department of Computer Science Indian Institute of Science – Bangalore Lecture – 54 Schnorr Signature Scheme e TLS o SSL (Fare Slide Time: 00.33) Ciao a tutti. Benvenuti a questa lezione. Il piano per questa lezione è il seguente e questa lezione discuteremo una trasformazione molto potente o euristica, che chiamiamo euristica Fiat - Shamir. Il che ci permette di ottenere schemi di firma digitale da qualsiasi schema di identificazione sicuro e poi vedremo come applicare questa trasformazione in nessun schema di firma per ottenere uno schema di firma digitale basato sull'assunzione discreta dei log. Infine, vedremo una panoramica del protocollo TLS e SSL. (Riferimento Slide Time: 01.00)Quindi, iniziamo la nostra discussione con la trasformazione Fiat - Shamir. Quindi, quello che fa la Fiat - Shamir euristica o la trasformazione, ci vuole qualsiasi schema di identificazione interattiva a 3 rotondi, che ha struttura di impegno, di sfida, di risposta. E la trasformazione converte quel protocollo interattivo in un protocollo non interattivo. Non interattivo nel senso che avrà un solo round di interazione dal prover al verificatore e utilizzando quel protocollo non interattivo in sostanza, finiamo per ottenere uno schema di firma a 1 giri. L'idea alla base di questa trasformazione è che, se si dispone di uno schema di identificazione e se si desidera ottenere un schema di firma in uscita, allora per firmare il messaggio utilizzando la chiave di firma, il firmatario deve agire come prover e deve eseguire l'intero protocollo dello schema di identificazione nella sua mente. Come per le regole di questa trasformazione, vieni con tutta la trascrizione in un solo colpo e darla al verificatore. Il che significa, nel protocollo interattivo di 3 minuti che c'era per lo schema di identificazione, la sfida sarebbe stata prelevata dal verificatore. Ma quello che stiamo dicendo qui è che dopo aver fatto questa trasformazione, anche la sfida sarà scelta anche dal provino stesso. Deve svolgere il ruolo del provino oltre che del verificatore contemporaneamente. Quindi, potreste chiedervi che se a prover è data la disposizione di scegliere la sfida per conto del verificatore, il prover malevolo o il provino imbroglioso possono barare. Potrebbe non scegliere una sfida uniformemente casuale. Si scopre che la trasformazione Fiat - Shamir è talmente intelligente che finisce per costringere anche il prover imbroglio a scegliere sfide uniformemente casuali. Ecco, ecco come facciamo la conversione del protocollo interattivo di 3 round in 1 round di protocollo interattivo. Così, ci viene dato uno schema di identificazione a 3 round Gen, 1, 2,. Utilizzandolo, vogliamo ottenere il segno dello schema di firma a 1 giri = (Gen, Sign, Vrfy). Nell'ambito di questa trasformazione, supponiamo di avere la descrizione pubblica di alcune funzioni hash mapping di lunghezza arbitraria agli elementi dello spazio di sfida dello schema di identificazione sottostante. Quindi, l'algoritmo di generazione chiavi di questo schema di firma, sarà lo stesso dell'algoritmo di generazione chiavi del tuo schema di identificazione. Ora l'algoritmo di firma è il seguente. Immagina, c'è un firmatario che ha la chiave di firma, e ha un messaggio su cui vuole generare la sua firma. Così, come ho detto in precedenza, deve svolgere il ruolo di prover nonché il verificatore dello schema di identificazione stesso. Quindi, esegue l'algoritmo P1 sul tasto di firma per ottenere l'impegno I e un'informazione di stato, e ora deve scegliere la sfida casualità r per conto del verificatore stesso. Quindi, idealmente dovrebbe scegliere la sfidante casualità r uniformemente casualmente dallo spazio di sfida, ma ora progettiamo uno schema di firma. Quindi, anche il messaggio dovrebbe entrare nella foto mentre raccogliendo la casualità r o lo sfidante r. Quindi, per scegliere la sfida. Quindi, l'idea qui è fondamentalmente, la sfida r sarà in qualche modo associata al messaggio, che il mittente vuole firmare qui. E se supponiamo o se modelliamo la funzione hash sottostante come oracolo casuale qui, si scopre che il valore r, che firmatario si otterrà generando r come per questo metodo, sarà infatti un valore uniformemente casuale dallo spazio di sfida del sottostante schema di identificazione. Una volta generata la r, il firmatario deve generare la parte di risposta, ovvero eseguendo l'algoritmo P2 e infine la firma è (r, s). Quindi, ora per inviare un messaggio firmato al verificatore, manderà solo un messaggio insieme alla firma (r, s). E il modo in cui il verificatore verifica la firma è, esegue l'algoritmo di verifica dello schema di identificazione sottostante, ma c'è una differenza. Nel regime di identificazione originale, il verificatore stava verificando se l'uscita dell'algoritmo di verifica con la chiave di verifica e la parte (r, s) della trascrizione dia la parte I della trascrizione o meno. Qui invece, la s parte dell'algoritmo di verifica dello schema di firma, il verificatore sta per eseguire l'algoritmo di verifica dello schema di identificazione sottostante, ma non confronta l'output della funzione V con il componente I , perché non conosce il componente I così com' è. Se si vede la struttura di questo schema di firma, il I non è dato dal firmatario al verificatore, mentre nello schema di identificazione il verificatore avrebbe già ottenuto un I ed è per questo che potrebbe confrontare l'output della funzione V con l'impegno I dato dal prover. Così, nell'algoritmo di verifica dello schema di firma, I viene calcolato da scratch dal verificatore eseguendo la funzione V e idealmente questo I dovrebbe essere lo stesso I, che un legittimo prover nello schema di identificazione avrebbe commesso a un verificatore onesto. Ora, per verificare la firma ciò che fa il verificatore, ha ora il valore I , ha ora il valore m e i controlli. Poi accetta la firma, altrimenti respinge la firma. Idealmente, se effettivamente il firmatario e il firmatario è onesto, allora il I generato eseguendo la funzione di verifica o la funzione V sulla chiave di verifica r e s avrebbe dato un I, tale che dovrebbe effettivamente essere uguale a r. Quindi, la dichiarazione teorica che possiamo provare qui è che se ci si trova nel modello casuale - oracolo e se questo schema di identificazione pi è uno schema di identificazione sicuro, allora lo schema di firma che abbiamo generato qui di fatto è uno schema di firma sicuro. La prova è leggermente coinvolta e dobbiamo entrare nei tecnicismi del modello casuale - oracolo. Quindi, sto saltando la prova formale completa, vedremo solo una panoramica della prova, potete vedere la prova formale completa nel libro di Katz e Lindell. L'idea qui è che se si vede la distribuzione di r che il firmatario ha generato nell'algoritmo di firma, la sua distribuzione è esattamente la stessa che sarebbe stata in una vera e propria esecuzione dello schema di identificazione, purché si trovi nel modello casuale - oracolo. Il che significa, anche il firmatario è corrotto, non ha alcun controllo sulla casualità r perché sarà un valore uniformemente casuale, perché sarà un output dell'oracolo casuale. Il modo in cui abbiamo progettato lo schema di firma, nell'algoritmo di firma, la casualità r, o la sfida r, che il firmatario sta generando, è sostanzialmente una funzione sia dell'impegno I sia del messaggio su cui vuole generare la firma. Quindi, se abbiamo un avversario che vuole forgiare una firma per conto di firmatario senza conoscere realmente il tasto firma sk, allora sostanzialmente quello che il forger deve fare è senza conoscere la chiave di firma, deve arrivare con alcune informazioni di I e dello stato e deve arrivare con qualche sfida r, querelando l'oracolo casuale, e deve arrivare con qualche risposta s, tale che nel complesso è una trascrizione accettante, ovvero (I, r, s) è una trascrizione accettante e non solo quella uscita del casuale - oracolo sull'impegno I e il messaggio è uguale a r. Tutta questa cosa deve fare a meno di conoscere davvero la chiave di firma. Se esiste un avversario che può effettivamente farlo con una probabilità significativa, allora intuitivamente vuol dire che ha un avversario che può addirittura forgiare o che può spezzare la sicurezza di questo schema di identificazione sottostante, ovvero, anche senza conoscere la chiave di firma o la chiave segreta, sk, quell' avversario potrebbe inventarsi una legittima trascrizione per conto del prover e convincere il verificatore e farlo accettare. Ma questo va contro l'ipotesi che lo schema di identificazione sottostante sia uno schema di identificazione sicuro. Ecco quindi un'idea intuitiva dietro questa Fiat - Shamir Transformation. Non sto entrando nei dettagli formali completi. (Riferimento Slide Time: 10.20)Ora, vediamo come possiamo applicare la trasformazione Fiat - Shamir sul regime di identificazione dovuto a Schnorr e di conseguenza otteniamo uno schema di firma, che chiamiamo Schnorr Signature Scheme. Sottolineo che questa trasformazione Fiat - Shamir è una trasformazione generica. Può essere applicato su qualsiasi schema di identificazione, su qualsiasi schema di identificazione a tre piani, per ottenere uno schema di firma a 1 giri. Qui la applichiamo nell'ambito del sistema di identificazione Schnorr. Quindi, ricordati che nel Sistema di identificazione Schnorr, la chiave segreta:, e lo schema di identificazione è il seguente: il prover nello schema di identificazione vuole sapere, quindi dimostrare che si impegna, presentando gk. Il verificatore lancia un misto lineare casuale r e il prover deve arrivare con una risposta s. Ovvero una combinazione lineare (mod e il verificatore verifica il − = oppure no. Se si applica l'euristico Fiat - Shamir sul regime di identificazione, l'algoritmo di generazione chiave dello schema di firma sarà il seguente: la chiave di verifica dove la corrispondente chiave di firma:. Insieme a quello, ci sarà una descrizione pubblicamente nota di una funzione hash volta ⇒ Z, perché lo spazio di sfida qui non è altro che Z. L'algoritmo di firma sarà il seguente: immaginate ci sia un firmatario con un per firmare un messaggio m. Prima calcola l'impegno raccogliendo un valore scelto casualmente, e poi picchia la sfida per conto del verificatore chiamando, calcola il mod di risposta e la firma è (r, s, m). Per verificare la firma, il verificatore deve generare l'impegno assunto −, e qualunque cosa ne venga fuori, che viene trattato come l'impegno del firmatario per il sottostante schema di identificazione Schnorr. Poi il verificatore genera la sfida che questo impegno computato e il messaggio che il firmatario sta inviando avrebbero prodotto, quindi per questo il verificatore chiama casuale - oracolo Output 1, iff, che il firmatario sta affermando di far parte della firma. Per quanto riguarda la sicurezza dell'euristica Fiat - Shamir, questo schema di firma a 1 giri è infatti uno schema di firma di sicurezza nel modello casuale - oracolo. Quindi, ora abbiamo uno schema di firma candidato basato sull'assunzione discreta di log. Si è scoperto che Schnorr ha brevettato questa idea. Così, ha sostanzialmente brevettato il suo tre round di identificazione, quindi di conseguenza lo schema di firma che esce applicando la trasformazione Fiat - Shamir è considerato anche brevettato, quindi non possiamo utilizzarlo in ambito pubblico. Quindi quello che ha fatto NIST, ha sviluppato una variazione dello schema Schnorr Identification e applicando la trasformazione Fiat - Shamir su quella variante, ha ottenuto uno schema di firma basato sull'assunzione discreta di log, che chiamiamo DSA, Digital Signature Algoritmo. Si tratta di uno standard ben noto che utilizziamo in pratica e il gruppo sottostante che utilizziamo in questo algoritmo DSA è il gruppo basato sul punto delle curve ellittiche modulo prime, poi l'istanziazione del DSA è chiamata ECDSA, Elliptic Curve Digital Signature Algoritmo e questo è un algoritmo di firma digitale molto popolato utilizzato in diverse applicazioni mondiali reali. (Riferimento Slide Time: 14.48) Così, ora più o meno arriviamo al termine della discussione sulla crittografia a chiave pubblica. Abbiamo visto instanziare lo schema di crittografia, le firme digitali e così via. Durante la prima metà del corso abbiamo discusso rigorosamente di crittografia chiave simmetrica. Così, ora vedremo che come combinare vari primitivi crittografici in entrambi i mondi, si arriva con un vero e proprio protocollo di comunicazione sicuro mondiale. Quindi quello che discuterò è una panoramica molto alta del protocollo SSL, che in realtà è il successore del protocollo TLS e questo è solo una panoramica di altississimo livello. Non dovremmo trattare la discussione come una vera e propria implementazione dell'SSL per i dettagli esatti in completa analisi del protocollo SSL. È necessario fare riferimento a qualsiasi testo standard nella sicurezza di rete. Ecco, ecco come funziona il protocollo SSL. Quindi, immaginate di avere un computer e nel vostro browser, digita https seguito da alcuni xyz.com, diciamo google.com. Così appena digiti https, i s qui denotano di voler avviare una sessione di comunicazione sicura con il server chiamato mail.google.com. E non appena digiti questo in realtà il protocollo SSL inizia a eseguire, e come parte di questo protocollo SSL, ci sono due sottoprotocolli, che vengono eseguiti. Esiste un protocollo handshake dove avviene qualche interazione tra il client, che il browser in questo caso e server è google.com in questo caso. Per quanto riguarda il protocollo handshake se tutto va bene, allora viene stabilito un tasto tra il server e il client. Quindi, per iniziare con il client, e il server non aveva informazioni pre - condivise ma non appena il protocollo di handshake viene eseguito e lo scambio di chiavi autenticato avviene tra il server e il client. Se il protocollo handshake ha esito positivo, la chiave verrà stabilita correttamente tra il server e il client. Ora, una volta stabilito il tasto, il secondo sottoprotocollo che viene avviato l'esecuzione è il protocollo a livello record. Questo protocollo a strati da record quello che fa è la comunicazione privata autenticata tra il server e il client utilizzando le chiavi che sono state stabilite durante il protocollo handshake. In termini di primitivi crittografici per effettuare lo scambio di chiavi autenticato, il protocollo handshake utilizza la crittografia a chiave pubblica mentre una volta stabilito il tasto per effettuare la comunicazione effettiva tra il server e il client, il protocollo layer - layer utilizza i primitivi di chiave privata. Ora si vede che come esattamente i vari primitivi crittografici si combinano per fare o risolvere l'intero problema della comunicazione sicura qui. Quindi ora andiamo un po' più a fondo nei dettagli del protocollo handshake e del protocollo layer. Quindi, ricordate l'obiettivo del protocollo handshake è quello di fare uno scambio di chiavi autenticato tra il client e il server. Immaginate che il server abbia una sua chiave pubblica e una chiave di decodifica per un meccanismo di incapsulamento sicuro CCA e immaginate di avere a disposizione varie autorità certificate nel mercato che hanno la loro chiave di firma e di verifica.In questo esempio, presumo che ci siano quattro autorità certificate, e presumo qui che la chiave di verifica delle autorità certificate sia già preconfigurata nel browser, utilizzata dal client. Quindi, se volete potete andare alle impostazioni del browser che state utilizzando e potete vedere la chiave di verifica delle note autorità certificate, già incorporate nei vostri browser. Presumo anche qui che il server in questo caso abbia un certificato rilasciato dalle autorità del secondo certificato che certifichi la sua chiave di codifica o la chiave pubblica e tale certificato sia disponibile con il server. Così, non appena il protocollo di handshake inizia a eseguire l'esecuzione tra il client e il server, il primo messaggio passa dal client al server, dove sostanzialmente il client invia i cifrati supportati e cioè quale versione della funzione hash supporta, quale versione di cifratura di blocco supporta, quale versione di generatore di pseudorandom supporta, e così via e insieme a che il client invia il valore nonce scelto casualmente. In risposta, il server sceglie un nonce casuale, e invia ciò che i ciphersuiti sostiene, ovvero la sua versione di hash function, la sua versione di cifrature bloccabili, i generatori di pseudorandom e così via. E insieme a che il server invia la chiave pubblica del suo meccanismo di incapsulamento chiave, e a convincere che effettivamente questa chiave pubblica appartiene al cosiddetto server, il mittente invia il certificato che potrebbe aver ottenuto da una di queste autorità certificate. In questo esempio si tratta della seconda autorità di certificazione. Quindi, in sostanza l'idea qui è che sia il client che il server stanno cercando di accordarsi sulla versione dei cifrati che useranno per il resto della comunicazione, e insieme al fatto che il server sta inviando la sua chiave di codifica o la chiave pubblica e dimostrare che effettivamente la chiave pubblica appartiene al server inviando il corrispondente certificato. Ora, quello che fa il cliente, verifica o verifica il certificato. Per verificare il certificato, utilizza la chiave di verifica dell'autorità di certificazione che ha rilasciato tale certificato al server, e in questo caso il certificato è stato rilasciato dalla seconda autorità di certificazione. La chiave di verifica della seconda autorità di certificazione verrà utilizzata e se solo il certificato verrà verificato con successo, la comunicazione procederà ulteriormente, altrimenti il cliente interrompe la sessione in esso presente in italtr.Ora, potrebbe essere possibile che il certificato sia rilasciato da un'autorità di certificazione la cui chiave di verifica non è incorporata nel browser del client. In tal caso, questa verifica non avrà alcun output. Di conseguenza, il browser lancerà un messaggio di avvertimento all'utente o al cliente cioè dicendo che, “ non posso identificare, o non riesco a riconoscere la validità del certificato ”. Si tratta di un messaggio di errore comune, che molto spesso si incontrano quando cerchiamo di fare una comunicazione SSL con un server, il cui certificato non può essere riconosciuto dal nostro browser. Otteniamo il messaggio di avvertimento che puoi procedere a tuo rischio. Ecco perché si consiglia sempre di aggiornare le versioni del proprio browser in quanto ogni volta che si arriva con la nuova versione del browser, la chiave di verifica delle nuove autorità certificate viene incorporata nelle nuove versioni e da qui non si otterrà questo tipo di messaggio di errore. Per questo esempio, presumo che la chiave di verifica dell'autorità del certificato sia disponibile con il client e il certificato sia verificato correttamente. Una volta che avviene la verifica del certificato, ora quello che fa il cliente, esegue l'algoritmo di incapsulamento del meccanismo di incapsulamento della chiave sottostante utilizzando la chiave pubblica fornita dal server. Di conseguenza, si produrrà una chiave segreta, che dengo come pmk. L'incapsulamento di questo pmk non è altro che chiave prepadronale. Così, questo algoritmo di incapsulamento avrà in output una chiave premaster e la sua incapsulazione c. L'incapsulamento c verrà inviato al server e ciò che il cliente sta per fare è, si sta andando a eseguire una funzione di derivazione chiave sugli input Nc e Ns, ovvero le due nonces, che vengono prelevate rispettivamente dal client e dal server, la chiave premaster e l'output sono considerati come una chiave principale. Inoltre, qualunque sia la comunicazione avvenuta tra il cliente e il server fino ad ora incluso questo incapsulamento c, lasciatelo chiamare come trascrizione. Questo client di trascrizione intero si autentica utilizzando un codice di autenticazione del messaggio e utilizzando la chiave principale come chiave e il tag corrispondente viene inviato al server. Ecco, questo è un messaggio ora dal lato client. Ciò che il server fa è, prende l'incapsulamento c ed esegue l'algoritmo di decapsulamento su questa incapsulazione c per ottenere lo stesso premaster key pmk. Una volta che ottiene la chiave premaster, esegue la funzione di derivazione chiave sui due valori nonce e la chiave premaster per ottenere la chiave principale.Quindi, ora come per il nostro presupposto sia il client che il server avrebbero concordato le versioni della funzione di derivazione chiave che useranno perché quella è la parte delle suite di cifratura supportate. Garantisce che sia il client che il server utilizzano la stessa versione della funzione di derivazione chiave e la stessa versione del meccanismo di incapsulamento chiave. Ora, il server fa anche il seguente passo. Così, ha visto ora l'autenticazione di tutta la trascrizione che il cliente ha inviato ad esso, quindi verifica il cartellino sulla trascrizione che il client vi sta inviando e interrompe se la verifica del cartellino fallisce. Mentre se la verifica del cartellino ha successo, effettua quanto segue: esegue un generatore di pseudorandom sulla chiave principale e deriva quattro tasti, che sono denotati da kc, kc m., ks, ks. Inoltre, qualunque sia la trascrizione ora che il server ha visto fino ad ora, la chiamiamo trascrizione e questo include tutta la cosa che il cliente ha inviato ad essa seguito dall'autenticazione della trascrizione che il client ha inviato al server. Tutta questa cosa la chiamo come trascrizione e questa trascrizione è ora autenticata dal server utilizzando il master key mk e il tag viene inviato al client. Quello che il client sta per fare è, effettuerà una verifica sulla trascrizione che utilizza la chiave principale. Se la verifica fallisce, si interrompe, altrimenti esegue anche lo stesso generatore di pseudorandom, che è stato eseguito dal server sul master key mk, e deriva gli stessi quattro tasti, che il server ha generato. Questo completa il protocollo handshake. Ora, potete vedere in questo protocollo intero handshake, usiamo la chiave pubblica primitiva e cioè il meccanismo di incapsulamento chiave, e insieme a questo stiamo utilizzando la funzione di derivazione chiave e un generatore di pseudorandom. Fino alla fine del protocollo handshake, le crittografie effettive dei messaggi, che il cliente vorrebbe comunicare al server non sono accaduta. Fino ad ora, solo lo scambio chiave è avvenuto e lo scambio chiave richiama solo il meccanismo di incapsulamento chiave insieme alla funzione di derivazione chiave e al generatore di pseudorandom. Ora, ipotizzando che il protocollo di handshake venga eseguito con successo, sia il server che il client hanno ora due coppie di chiavi. Ogni qualvolta il server desidera comunicare qualcosa al cliente, esegue uno schema di crittografia autenticato utilizzando la coppia di chiavi ks e ks e possiamo utilizzare qualsiasi schema di crittografia autenticato qui, diciamo quello ottenuto utilizzando la cripta, poi l'autenticazione meccanismo. In risposta ogni qualvolta il client desidera comunicare qualcosa al server, utilizza l'altra coppia di chiavi ovvero il kc chiave, e la chiave kc &ldé.Si può ricordare che nell'approccio generico che avevamo visto costruire lo schema di crittografia autenticata, sottolineiamo che ci dovrebbe essere una chiave indipendente per istanziare lo schema di crittografia sicuro CPA che c'è all'interno dello schema di crittografia autenticata e ci dovrebbe essere una chiave indipendente per istanziare il componente MAC, che c'è nello schema di crittografia autenticata ed è per questo che c'è un paio di chiavi, che viene utilizzato nello schema di crittografia autenticata. Abbiamo un paio di chiavi dedicate ogni qualvolta il server vuole comunicare con il cliente e abbiamo le chiavi dedicate ogni qualvolta il cliente vuole comunicare al server. Ora è possibile vedere che per fare la comunicazione effettiva tra il client e il server, stiamo utilizzando un processo di codifica chiave completamente simmetrico. (Riferirsi Slide Time: 27:45) Così da riassumere, dovremmo sicuramente ringraziare questi due geni Diffie e Hellman che hanno pensato di risolvere il problema dell'accordo chiave mentre il mittente e il destinatario che sono collegati da un canale in comunicazione in comunicazione pubblica e ancora possono finire concordi su una chiave privata casuale comune conosciuta solo al mittente e al destinatario. Solo grazie alla loro visione e a causa del lavoro pionieristico è emersa tutta l'area della crittografia a chiave pubblica ed è così che potremmo pensare di fare comunicazione sicura con qualsiasi persona sconosciuta con cui non abbiamo mai incontrato, con cui non abbiamo mai condiviso alcun tipo di informazione segreta e possiamo convenientemente fare comunicazione sicura con quelle sconosciute people.Quindi, dovremmo sicuramente ringraziare queste due persone a causa dell'impatto del lavoro che quello che hanno fatto, vengono premiati molto recentemente. Questo è tutto per questa lezione. Così solo per riassumere in questa lezione, abbiamo visto, abbiamo discusso di altissimo livello che abbiamo la Fiat - Shamir euristica e come possiamo applicarla per convertire qualsiasi schema di identificazione a tre round in uno schema di firma. L'abbiamo applicato concretamente per lo schema di identificazione Schnorr per ottenere lo schema di firma Schnorr e abbiamo discusso una panoramica di altissimo livello del protocollo SSL e un protocollo TLS. Così, che più o meno finisce la nostra discussione sul problema della comunicazione sicura. Ora sappiamo come fare una comunicazione sicura tra due entità su un canale pubblico dove il mittente e il destinatario potrebbero non avere informazioni pre - condivise. Per le restanti lezioni vedremo come possiamo utilizzare primitivi crittografici per progettare protocolli interattivi dove