4. Security Considerations (Considerazioni sulla sicurezza)
4. Security Considerations (Considerazioni sulla sicurezza)
Il cifrario ChaCha20 è progettato per fornire sicurezza a 256 bit.
L'autenticatore Poly1305 è progettato in modo che i messaggi contraffatti vengano rifiutati con probabilità 1-(n/(2^102)) per un messaggio di 16n byte, anche dopo l'invio di 2^64 messaggi legittimi ; è quindi SUF-CMA (strong unforgeability against chosen-message attacks, forte non falsificabilità contro attacchi a messaggio scelto) nella terminologia di [AE].
Dimostrare la sicurezza dell'uno o dell'altro algoritmo esula dall'ambito di questo documento. Tali dimostrazioni sono disponibili negli articoli accademici citati ([ChaCha], [Poly1305], [LatinDances], [LatinDances2] e [Zhenqing2012]).
La considerazione di sicurezza più importante nell'implementazione di questo documento è l'unicità del nonce usato in ChaCha20. I contatori e gli LFSR (linear feedback shift registers, registri a scorrimento con retroazione lineare) sono entrambi modi accettabili per generare nonce unici, così come la cifratura di un contatore con un cifrario a blocchi con dimensione di blocco di 64 bit come DES. Non è accettabile usare un troncamento di un contatore cifrato con cifrari a blocchi con blocchi da 128 o 256 bit, perché un tale troncamento può ripetersi dopo poco tempo.
Conseguenze della ripetizione di un nonce: se un nonce si ripete, sia la chiave Poly1305 monouso sia il keystream sono identici tra i messaggi. Ciò rivela lo XOR dei testi in chiaro, perché lo XOR dei testi in chiaro è uguale allo XOR dei testi cifrati.
La chiave Poly1305 DEVE essere imprevedibile per un attaccante. La generazione casuale della chiave soddisferebbe questo requisito, salvo che Poly1305 è spesso usato in protocolli di comunicazione, quindi il ricevente deve conoscere la chiave. La generazione di numeri pseudocasuali, ad esempio cifrando un contatore, è accettabile. Anche l'uso di ChaCha con chiave segreta e nonce è accettabile.
Gli algoritmi qui presentati sono stati progettati per essere facili da implementare a tempo costante, al fine di evitare vulnerabilità da canale laterale. Le operazioni usate in ChaCha20 sono tutte addizioni, XOR e rotazioni fisse. Tutte possono e dovrebbero essere implementate a tempo costante. L'accesso agli offset nello stato ChaCha e il numero di operazioni non dipendono da alcuna proprietà della chiave, eliminando la possibilità che informazioni sulla chiave fuoriescano tramite i tempi dei cache miss.
Per Poly1305, le operazioni sono addizione, moltiplicazione e modulo, tutte su numeri di oltre 128 bit. Ciò può essere fatto a tempo costante, ma un'implementazione naïf (ad esempio con una libreria generica per interi grandi) non sarà a tempo costante. Ad esempio, se la moltiplicazione è eseguita separatamente dal modulo, il risultato sarà talvolta inferiore a 2^256 e talvolta superiore. Gli implementatori devono prestare attenzione ai canali laterali di temporizzazione per Poly1305 usando implementazioni appropriate di queste operazioni.
Convalidare l'autenticità di un messaggio comporta un confronto bit a bit del tag calcolato con il tag ricevuto. Nella maggior parte dei casi d'uso, nonce e contenuti AAD (associated authenticated data, dati autenticati associati) non vengono "consumati" finché non si riceve un messaggio valido. Ciò consente a un attaccante di inviare più messaggi identici con tag diversi finché uno supera il confronto dei tag. È difficile se l'attaccante deve provare tutti i 2^128 tag possibili uno alla volta. Se tuttavia i tempi dell'operazione di confronto dei tag rivelano quanto è lungo un prefisso comune tra tag calcolato e tag ricevuto, il numero di messaggi può ridursi sensibilmente. Per questo motivo, con i protocolli online, l'implementazione DEVE usare una funzione di confronto a tempo costante anziché affidarsi a funzioni di libreria ottimizzate ma insicure come memcmp() del linguaggio C.
Inoltre, ogni protocollo che usa questo algoritmo DEVE includere il tag completo per ridurre al minimo le opportunità di falsificazione. Il troncamento del tag NON DEVE essere effettuato.
<｜tool▁calls▁begin｜><｜tool▁call▁begin｜> StrReplace