Informazioni sulle crittografie nella lista nera per HTTP2

Come l'appendice rfc4880 che hai collegato a dice

  Note: This list was assembled from the set of registered TLS
  cipher suites at the time of writing.  This list includes those
  cipher suites that do not offer an ephemeral key exchange and
  those that are based on the TLS null, stream, or block cipher type
  (as defined in Section 6.2.3 of [TLS12]).  Additional cipher
  suites with these properties could be defined; these would not be
  explicitly prohibited.

Le suite di streaming sono nella lista nera perché l'unico codice di flusso usato in TLS è RC4 e gli attacchi contro RC4 sono praticamente esplosi negli ultimi anni; vedi rfc 7465 .

Le suite CBC sono nella lista nera perché ora è riconosciuta TLS-nee-SSL l'uso di MAC-then-encrypt è stata una scelta sbagliata (anche se prima del primo chiaro riconoscimento di questo, Bellare & Namprempre in Asiacrypt 2000) in parte perché MTE combinato con CBC (che richiede il riempimento) in un protocollo online consente attacchi di padding-oracle come POODLE e Lucky13. POODLE interrompe gravemente SSL3, ma SSL3 era già ufficialmente obsoleto e POODLE alla fine ha motivato le persone a eliminarlo. Lucky13 richiede tempi precisi e non è molto pratico ora, ma mostra un approccio che potrebbe migliorare. (L'uso di SSL e TLS1.0 di IV esposto per CBC ha consentito anche BEAST, ma quella parte è stata risolta in 1.1 e 1.2.)

I numeri nulli sono in lista nera perché, beh, la loro indesiderabilità dovrebbe essere ovvia.

Questo lascia solo suite AEAD, e in pratica solo GCM, almeno per ora. Si noti che AEAD richiede TLS1.2, che non è ancora implementato universalmente, pertanto test generici come SSLLab accettano ancora le modalità CBC per consentire server e / o client che utilizzano 1.1 e 1.0 (ma non SSL3 come sopra). Chrome ha usato per descrivere qualsiasi cosa diversa dalla versione 1.2 con AEAD e lo scambio di chiavi effimero come "crittografia obsoleta", e security.SX ne ha parecchi Qs, ma su retest (51.0.2704.84) sembra essersi fermato. HTTP / 2, che arriva dopo che TLS1.2 e AEAD "dovrebbero" essere già presenti, possono essere ragionevolmente più impegnativi.

A meno che non diventiamo dei computer quantistici pratici - molto grandi se la gente non è preoccupata - la differenza di forza tra AES-128 e AES-256 è priva di significato . È la differenza tra "indissolubile nella nostra galassia, ma potrebbe essere spezzata da qualcuno che controlla l'intero universo per miliardi di anni" e "indistruttibile persino nell'intero universo". Non importa quanto sia perversa la tua collezione di video di gatti, non ti importa se viene decifrato dopo che sei morto da tempo, tutti i tuoi discendenti sono morti, tutti gli esseri umani sono morti, e il nostro pianeta e il nostro sistema solare non esistono più.

(Sebbene abbia fornito tutte le altre funzionalità multimediali aggiunte in HTTP / 2, sono deluso dal fatto che non aggiungono alcuna possibilità di vietare o almeno limitare seriamente e degradare i video di gatto. Beh, c'è sempre X-.)

Gli algoritmi di crittografia hanno lo scopo di oscurare l'input originale dall'output senza la conoscenza della chiave. Idealmente, la modifica di qualsiasi bit nella chiave dovrebbe comportare la modifica di diversi bit nell'output e dovrebbe avvenire in un modello apparentemente imprevedibile. Gli algoritmi della lista nera sono stati sottoposti ad un'attenta analisi e sono risultati privi di questa caratteristica per un numero significativo di bit chiave. Questo è il motivo per cui vedrai spesso una "forza bit efficace" per un dato algoritmo, ed è solitamente più piccola dei bit della chiave (perché molti algoritmi invariabilmente perdono alcuni bit). In altre parole, più appare casuale l'output, più è efficace.

Ad esempio, una chiave a 256 bit in un determinato algoritmo potrebbe fornire solo 56 bit di sicurezza, mentre una chiave a 128 bit in un altro algoritmo potrebbe fornire 96 bit di sicurezza. Quando è suddiviso in questo modo, è facile vedere che la chiave a 128 bit è superiore alla chiave a 256 bit, nonostante sia la metà delle dimensioni, e quindi 2 ¹²⁸ volte più piccole in termini di valori possibili. Questo è uno dei motivi per cui "xor encryption" è considerato debole: puoi facilmente applicare una funzione all'output e indovinare la chiave e input, a meno che non siano soddisfatte determinate condizioni.

La ragione per cui le liste nere di HTTP / 2 certi algoritmi è di iniziare con una solida base di cifrari che sarà fattibile per il prossimo futuro. Non è possibile elencare continuamente gli algoritmi e aspettarsi che tutti i server e i client siano in linea con l'elenco in tempo reale. Pertanto, respingendo quei cifrari già spezzati o in pericolo di rottura nel prossimo futuro, ha più tempo a gestire la crescita esponenziale dell'informatica.