AES_GCM e il numero di sequenza TLS

Question

AES_GCM e il numero di sequenza TLS

#1 da (2 voti)

1

Ho ragione riguardo al fatto che la crittografia / decodifica di AEAD utilizza due volte un numero di sequenza TLS, la prima volta nel nonce e un secondo nei dati aggiuntivi?

E perché hanno reso il numero di sequenza TLS 1.2 2 volte più grande del numero di sequenza TSP? Perché hanno bisogno di questo overhead?

Informazioni aggiuntive su rfc5246 # page-25

The additional authenticated data, which we denote as additional_data, is defined as follows:
additional_data = seq_num + TLSCompressed.type +
                        TLSCompressed.version + TLSCompressed.length;

Informazioni su nonce da rfc5288 # page-2

        struct {
            opaque salt[4];
            opaque nonce_explicit[8];
         } GCMNonce;
The salt is the "implicit" part of the nonce and is not sent in the packet. Instead, the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). The salt length (SecurityParameters.fixed_iv_length) is 4 octets.

The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in the GenericAEADCipher.nonce_explicit field. The nonce_explicit length (SecurityParameters.record_iv_length) is 8 octets.

Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.

cryptography tls aes

posta Ark 22.10.2015 - 20:53

fonte

1 risposta

Leggi altre domande sui tag cryptography tls aes

Esistono strumenti / metodi per testare le penne per reti wpa2 che non richiedono l'uso di un adattatore che supporti la modalità monitor? [chiuso] Posso avere CA con JSSE

score 2 · Accepted Answer

Il numero di sequenza MAY può essere utilizzato due volte.

Prima c'è, in effetti, il numero di sequenza, che è il numero di record inviati dall'ultima stretta di mano. Questo valore è ciò che viene utilizzato nei "dati aggiuntivi" per le suite di crittografia AEAD (nelle suite di crittografia CBC + HMAC, il numero di sequenza è parte dell'input dell'HMAC).

Poi c'è anche la IV per-record, che deve avere una lunghezza di 12 byte; in TLS 1.2, questi 12 byte sono la concatenazione di un valore implicito a 4 byte (quello calcolato dallo scambio di chiavi) e un campo esplicito di 8 byte per record. Il mittente è responsabile della scelta di quel valore a 8 byte, con l'avvertenza che qualsiasi dato valore NON DEVE essere riutilizzato (con la stessa chiave). Tuttavia, GCM non è schizzinoso in merito a tale IV, purché sia rispettata la regola del "non riutilizzo". Pertanto, molte implementazioni lo ritengono opportuno utilizzare un semplice contatore, e la conseguenza è che il contatore sarà sincronizzato con il numero di sequenza, dal momento che entrambi saranno incrementati per ogni record in uscita. Questo non è un problema.

TLS 1.2 potrebbe essere stato definito per utilizzare il numero di sequenza direttamente per GCM per-record IV; questo avrebbe salvato 8 byte in ogni record. Sarebbe andato bene. Tuttavia, il salvataggio non è grande: si desidera salvare i byte quando si inviano molti dati e probabilmente si utilizzano grandi record (16384 byte di testo in chiaro per record), quindi 8 byte extra non sono relativamente un grosso problema. / p>

Perché TLS 1.2 è stato definito in questo modo è un po 'poco chiaro; bisognerebbe scavare nei verbali delle riunioni del comitato per vedere se c'era qualche ragione per questo. È una scommessa abbastanza sicura, tuttavia, che se ci fosse una "ragione", allora probabilmente era una vaga asserzione semi-dogmatica come "dobbiamo includere un campo esplicito perché potrebbe aiutare a contrastare un futuro attacco sconosciuto in alcuni ancora non specificato via".