Il secondo articolo (Safaka et al ) descrive un protocollo che si basa su un protocollo approssimativamente simile al protocollo Cachin-Maurer che descrivo alla fine di questa risposta . La premessa è che esiste un canale di comunicazione inaffidabile che trasmette tra le parti coinvolte, in modo che quando una delle parti emette un elenco di "pacchetti", tutti gli altri vedono solo alcuni del pacchetti, e non tutti vedono gli stessi pacchetti. Quindi Alice e Bob, desiderando stabilire un segreto condiviso, devono solo emettere un sacco di pacchetti, registrare ciò che ricevono e quindi dirsi a vicenda quale pacchetto hanno ricevuto (i pacchetti vengono referenziati da un ID convenzionale ). Con alta probabilità, l'utente malintenzionato non può vedere tutti i pacchetti registrati da Alice e Bob, quindi la concatenazione di tutti i pacchetti, opportunamente con hash, è una buona chiave condivisa.
Nel protocollo Cachin-Maurer, la trasmissione proviene da una sorgente casuale a larghezza di banda elevata e l'inaffidabilità della ricezione è dovuta all'impossibilità di registrare tutti i dati, a causa della sua dimensione. Nel protocollo Safaka, si presume che il mezzo di trasporto sia inaffidabile, il che è un po 'ottimistico perché l'hacker può investire in un'antenna buona , qualcosa di molto meglio nel raccogliere le onde radio rispetto agli adattatori WiFi di base di persone oneste.
Trasportare quel principio a livello di applicazione sembra difficile perché la caratteristica veramente fondamentale del "livello di applicazione", il motivo per cui la chiamiamo "applicazione", è la sua affidabilità . Ad esempio, i pacchetti IP non corretti sono inaffidabili: possono perdersi, duplicati, a volte alterati (l'ho visto: un router Cisco con RAM difettosa) e arrivano fuori servizio. Tuttavia, la prima cosa che le applicazioni fanno è applicare TCP , che porta affidabilità (attraverso riconoscimenti e ri-emissioni). Quando il trasporto è affidabile, è affidabile per tutti, incluso l'aggressore.
Questa è una tendenza generica: il tipo di protocollo di scambio chiave di cui stiamo parlando deve fare affidamento su un processo fisico che impone qualche imprevedibilità; nel protocollo Safaka, il processo fisico è il rumore radio che interrompe la ricezione di alcuni pacchetti. Il mondo dei computer, d'altra parte, è matematico piuttosto che fisico: vive e si sforza in un mondo astratto dove un po 'è un po' e non si capovolge a caso. Infatti, quando un bit RAM viene capovolto (si dice che si verifichi circa una volta ogni tre mesi in media per una data macchina, a causa di raggi cosmici ), la macchina potrebbe bloccarsi, a seconda di dove si trovava il bit indicato. L'intero principio di informatizzazione è di scappare dal mondo fisico e tenerlo il più lontano possibile. Questo impedisce intrinsecamente l'uso efficiente dei protocolli Safaka-like, e ancora di più quando andiamo più in alto nello stack dei livelli, cioè "a livello di applicazione", come lo metti.
Un secondo punto da sottolineare è che questi protocolli sono scambio di chiavi, non autenticazione . Possono fornire sicurezza solo contro gli attaccanti passivi, che osservano ma non interferiscono. Al giorno d'oggi non è un'ipotesi realistica. Molti attacchi alla rete comportano azioni positive da parte di aggressori; e alcuni attaccanti a bassa potenza possono essere descritti come "solo attivi": spesso è molto più facile inviare pacchetti falsi a un server piuttosto che intercettare i pacchetti tra un server e un client onesto.
Pertanto, è necessaria l'autenticazione: non si desidera scambiare una chiave in generale, ma una chiave con un client o un server specifico. Per fare ciò, è necessario un meccanismo di autenticazione che si verifichi sufficientemente all'inizio del processo, ad es. con le chiavi pubbliche o qualche PAKE , e si ritorna alla "normale crittografia", rendendo piuttosto i protocolli Safaka-like inutile.