Nella pratica, tutte le implementazioni di AEAD utilizzano cifrari a chiave simmetrica?
Tutto ciò che ho visto finora nelle implementazioni moderne (l' API AEAD del kernel Linux , il provider di crittografia JVM (AES-GCM), RFC 8439 , libsodium , ecc.) sembra implicare che nella pratica per AEAD vengano utilizzate solo cifrature a blocchi di chiavi simmetriche. Esistono algoritmi a chiave asimmetrica che garantiscono la crittografia autenticata?
Risposte
Quando le persone dicono "AEAD", hanno in mente schemi simmetrici. Ma concettualmente, la crittografia autenticata non è limitata alle chiavi simmetriche. È solo il caso che le varianti a chiave pubblica non hanno ricevuto molta attenzione sia in letteratura che nella pratica. Ma ci sono implementazioni. Ad esempio, NaCl ha un'API per la crittografia autenticata a chiave pubblica , basata sulle nozioni di sicurezza di Jee Hea An 2001 . La costruzione si basa sulla crittografia a chiave pubblica e sui MAC. Ciò dimostra che l'AE nell'impostazione asimmetrica è fondamentalmente diversa dalla semplice firma di messaggi crittografati, come spiegato nei documenti dell'API NaCL:
La funzione crypto_box non ha lo scopo di fornire il non ripudio. Al contrario: la funzione crypto_box garantisce la ripudiabilità. Un destinatario può modificare liberamente un messaggio inscatolato, e quindi non può convincere terzi che quel particolare messaggio provenga dal mittente. Il mittente e il destinatario sono comunque protetti da falsificazioni da parte di terzi. Nella terminologia dihttps://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d82c, crypto_box utilizza "autenticatori a chiave pubblica" anziché "firme a chiave pubblica".
Gli utenti che desiderano la verificabilità pubblica (o la verificabilità pubblica assistita dal destinatario) dovrebbero invece utilizzare le firme (o la crittografia dei segni).
Apparentemente questa API e la formalizzazione nel documento non includono la parte "dati aggiuntivi" (AD) di AEAD, ma non credo che ci sia una limitazione fondamentale. AEAD come singola primitiva nell'impostazione simmetrica è diventata popolare solo dopo il 2001, quindi credo che Jee Hea An semplicemente non abbia pensato ai "dati aggiuntivi" come una caratteristica utile nel 2001.
Posso solo ipotizzare, ma credo che uno dei motivi per cui la crittografia a chiave pubblica autenticata non ha ricevuto molta attenzione è che la crittografia a chiave pubblica (anche non autenticata) stessa è una primitiva usata raramente. La crittografia a chiave pubblica è utile in un ambiente in cui il mittente e il destinatario non sono online contemporaneamente. L'esempio principale è la crittografia della posta elettronica, ma sfortunatamente la crittografia della posta elettronica non è mai decollata per vari motivi ( Johnny Still, Still Can't Encrypt) e protocolli per la sicurezza della posta elettronica come PGP/GPG e S/MIME separano concettualmente riservatezza e autenticazione e li implementano tramite crittografia a chiave pubblica e firme digitali (e non MAC!). Ovviamente questi possono essere combinati ("firma-quindi-cifra", "cifra-poi-firma" o "cifra-e-firma") ma la responsabilità di farlo correttamente è per lo più attribuita all'utente, e il documento del 2001 mostra che tutte queste costruzioni sono insufficienti. (Uno dei motivi per cui PGP e S/MIME volevano esplicitamente le firme è che puoi ancora avere l'autenticazione per le e-mail pubbliche, ad esempio i post nelle mailing list pubbliche.)
Il successo dell'idea che dovremmo considerare la crittografia autenticata come un'unica primitiva con un'unica API resistente all'uso improprio i cui utenti non hanno bisogno di essere esperti di crittografia è arrivato solo più tardi nell'impostazione simmetrica dopo che le persone hanno sbagliato in modi infiniti con costruzioni come "encrypt- then-MAC", "MAC-then-encrypt", "encrypt-and-MAC", che sono le controparti simmetriche delle modalità sopra menzionate. Si noti tuttavia che le impostazioni simmetriche e asimmetriche sono difficili da confrontare quando si tratta di autenticazione, ad esempio, a causa delle citate sottigliezze con la ripudiabilità e la verificabilità pubblica. MAC e firme sono bestie molto diverse.
Gli AEAD sono simmetrici PER DEFINIZIONE . Inoltre, sono il punto di partenza da cui possiamo sostenere la sicurezza dei progetti di protocollo.
Gli schemi di crittografia autenticata asimmetrica sono noti come schemi signcrypt e PGP è probabilmente l'esempio più noto.
Nella pratica, tutte le implementazioni di AEAD utilizzano cifrari a chiave simmetrica?
Sì, ma è più per definizione che per riluttanza a quanto pare.
Tieni presente che sono necessarie due coppie di chiavi , una per la crittografia e una per la firma per ottenere la riservatezza e l'integrità/autenticità del messaggio offerte da uno schema AEAD. Ciò significa che qualsiasi schema AEAD per cifrari asimmetrici deve essere significativamente più complesso rispetto al senso simmetrico (anche il documento indicato da real-or-random mostra questa complessità). Poi c'è il problema dell'affidabilità delle chiavi pubbliche che potrebbe richiedere un'intera PKI. Pertanto penso che cose come la crittografia asimmetrica e la generazione della firma siano gestite a livello di protocollo.
Per i cifrari simmetrici aveva senso specificare i cifrari AEAD come una sorta di rilascio sicuro: usa questo e ottieni l'autenticità gratuitamente, usando una singola chiave (principalmente). Inoltre, con un cifrario AEAD come GCM o uno che utilizza Poly1305 si ottiene anche una buona velocità rispetto a HMAC. Questa è una proposta piuttosto diversa da quella richiesta per eseguire la crittografia autenticata utilizzando primitive asimmetriche.