Perché sono state definite le cifrarie CBC_SHA256 come TLS_RSA_WITH_AES_128_CBC_SHA256?

Question

Perché sono state definite le cifrarie CBC_SHA256 come TLS_RSA_WITH_AES_128_CBC_SHA256?

#1 da (1 voti)

3

Mi risulta che:

In TLS, la funzione di hash viene utilizzata solo nel costrutto HMAC.
SHA-1 è sicuro quando utilizzato in HMAC.
TLS 1.2 ha cambiato il PRF utilizzato per derivare le chiavi simmetriche a non più debole di SHA-2, indipendentemente da ciphersuite, quindi in TLS 1.2 la funzione hash denominata nella ciphersuite viene utilizzata solo per HMAC durante il trasferimento di dati collettivi.
TLS_RSA_WITH_AES_128_CBC_SHA256 non sembra più sicuro di TLS_RSA_WITH_AES_128_CBC_SHA, ma ha un sovraccarico di larghezza di banda maggiore (12 byte in più per ogni record, che può essere lungo fino a 16 KB).

È sopra corretto? Qual è stato il motivo alla base della definizione delle ciphersuites CBC SHA-2 in TLS 1.2? È stata una copertura contro HMAC_SHA1 che si è rotta in modo catastrofico, ma in modo tale da lasciare intatto HMAC_SHA256?

Se la mia analisi è corretta, significa che non ha senso supportare TLS_RSA_WITH_AES_128_CBC_SHA256? È questo il ragionamento dietro Android 5 e golang che non supporta CBC_SHA256?

Nota: conosco PFS e AEAD, questa è una domanda sui meriti di CBC_SHA256 rispetto a CBC_SHA.

tls

posta Z.T. 22.03.2015 - 00:40

fonte

1 risposta

Leggi altre domande sui tag tls

Heartbleed: durata del messaggio heatbeat? Come viene archiviata e gestita la chiave di crittografia Tresorit sul lato client?

score 1 · Accepted Answer

Ho letto la cronologia del lavoro su questa parte della specifica TLS.

Eric Rescorla (co-editore di TLS 1.1, 1.2 e 1.3) pubblicato il 31 dicembre 2007 sulla mailing list del gruppo di lavoro TLS di IETF relativa a un oggetto di lavoro denominato "Issue 66: HMAC-256 based ciphersuites" per la successiva bozza di TLS 1.2 (quindi chiamata RFC4346-bis, ovvero una revisione di TLS 1.1, ora noto come RFC 5246).

Il creatore dell'idea è sconosciuto.

Il motivo per aggiungere le nuove suite di crittografia è perché è strano per TLS 1.2 passare da PRF a SHA-256 e quindi non consentire SHA-256 per l'autenticazione di crittografia di massa.

L'idea è stata sostenuta da Uri Blumenthal (MIT Lincoln Lab) dicendo che SHA-1 ha dei punti deboli e non c'è bisogno di aspettare che si rompa prima che le sostituzioni siano definite.

Nikos Mavrogiannopoulos (autore di GnuTLS) supportava l'idea di far corrispondere la forza crittografica dei primitivi (specialmente di AES-256).

Pasi Eronen (Nokia, un sacco di lavoro su EAP) ha suggerito i nomi di alcune delle nuove suite di crittografia.

Poi ci fu un discorso sulla giusta dimensione della funzione di hash da abbinare a ogni cifra tra MIURA Fumiaki (Nippon Telegraph e Telephone), Florian Weimer (BFK, Red Hat, recentemente ha lavorato al fixing di Shellshock), Ken Peirce che suggerì di usa la metrica NIST "bit di sicurezza" per risolvere il dilemma, Jeffrey A. Williams e Bodo Möller (recentemente ha lavorato su Heartbleed) che hanno fornito collegamenti e spiegazioni sul fatto che "la sicurezza MAC a 128 bit dovrebbe essere perfetta anche per applicazioni che richiedono 256 bit sicurezza di crittografia ".

La specifica TLS è stata aggiornata (presumibilmente da Eric Rescorla) con le nuove suite di crittografia e pubblicata in bozza 8 pubblicata il 25 gennaio 2008.

La bozza del registro delle modifiche 8 riporta, in parte: "Aggiunto supporto per suite di crittografia SHA256", nessuna motivazione.

Nella versione finale della specifica, nella lista delle modifiche da TLS 1.1, dice "Aggiunte suite di crittografia HMAC-SHA256", ancora una volta, nessuna motivazione. L'elenco delle suite di crittografia nell'appendice C è rimasto invariato dal progetto 8.