C'è qualche ragione per usare la chiave privata 2 volte quando si crea un hash di sicurezza?

Questo costrutto può (crudemente) proteggere contro un attacco di estensione della lunghezza , che in particolare influisce sugli hash creati usando Costruzione Merkle-Damgård (come MD5, SHA-1 e SHA-2 famiglia).

L'essenza dell'attacco è che un attaccante che conosce H(s || m) e m per un hash H , segreto s e il messaggio m può banalmente forgiare un hash del formato H(s || m || p || a) dove p è il riempimento interno utilizzato dalla funzione di hash e a è una stringa controllata da un aggressore. Questo può sembrare difficile da sfruttare in pratica, poiché p è in genere byte non formattati come \x04\x04\x04\x04 . Tuttavia, considera un messaggio come un set di parametri di query HTTP: username=x&admin=false . Con questo attacco, puoi creare un messaggio "firmato" per username=x&admin=false\x02\x02&admin=true . A seconda di come vengono analizzati i parametri, il parser dell'URL potrebbe facilmente utilizzare l'ultimo valore di admin anziché il precedente.

L'hashing del segreto alla fine del messaggio è, presumibilmente, un tentativo di difendersi da questo tipo di attacco. Poiché l'hacker non conosce il segreto, non può utilizzare un attacco con estensione di lunghezza poiché non ha modo di falsificare H(s || m || p || a || s) senza conoscere s .

Detto questo, esistono costrutti crittografici che sono provati sicuri per l'uso come codici di autenticazione dei messaggi. In questo caso, HMAC è probabilmente la primitiva crittografica che vogliono utilizzare, in quanto ha una strong prova di sicurezza.

Questo tipo di costrutto interno è la prova che gli autori di questo servizio sono non esperti in crittografia. Se lo fossero, un HMAC sarebbe una scelta naturale e ovvia per una situazione del genere. Se sono disposti a pubblicare questi tipi di costrutti autocritici imbarazzanti nella loro documentazione pubblica, mi preoccuperei personalmente della crittografia che implementano e utilizzano internamente.

Baserò la mia risposta su un paio di ipotesi come sotto.

• La chiave segreta viene generata casualmente o non facilmente immaginabile
• La chiave segreta è solo questo, un segreto.

L'uso di due chiavi private in questa istanza non ha vantaggi per la sicurezza, presumendo che la chiave non sia mai stata utilizzata da terzi (quindi stai guardando gli attacchi di crittografia inversa).

Tuttavia, se il bisogno è derivato dal fatto che una terza parte potrebbe potenzialmente accedere a una chiave, allora se entrambe le chiavi private fossero archiviate in posizioni separate non accessibili direttamente dall'applicazione (basata su API / DB EG) allora forse aggiungerebbe un altro livello di sicurezza se il peggio dovesse accadere.