Esistono due tipi di Pinning della chiave pubblica HTTP, HPKP statico e HPKP dinamico.
HPKP statico
Almeno per Google Chrome, HPKP statico coinvolge un elenco di siti Web e le loro chiavi pubbliche effettivamente codificate in un file json distribuito con tutte le build di Chrome. Firefox lo conserva in un file di intestazione con una grande struttura contenente i siti web e le chiavi bloccate. Questo è simile al precaricamento di HSTS, ma tende a coinvolgere solo siti di profilo più alto, quindi non puoi inviarne uno tuo. Questa lista non è enorme, quindi è facile interrogarla rapidamente. Se includesse in particolare molti siti, non sarebbe scalabile.
HPKP dinamico
Questo è simile all'HSTS. Un server invia un'intestazione HTTP contenente la direttiva pin insieme a un'impronta digitale e un'impronta di backup. Come HSTS, codifica anche la durata per la quale questo sarà valido. Dopo aver ricevuto l'impronta digitale, il browser si collegherà al sito Web solo se corrisponde alla data di scadenza. Questo è archiviato in memoria o su disco e al massimo contiene solo il sito web visitato che utilizza l'HPKP dinamico. Supponendo che CA comprometta, HPKP fornisce in modo efficace una strong garanzia TOFU (Trust On First Use) su TLS.
L'effettiva implementazione probabilmente non è rilevante. Per l'HPKP statico, immagino che Firefox esegua semplicemente loops sulla struttura per trovare le corrispondenze e Chrome utilizzi il parser JSON interno per trovare le corrispondenze. Per l'HPKP dinamico, è probabilmente una sorta di elenco, se un elenco collegato o qualcosa di più veloce e leggero come un qualche tipo di albero, non lo so. In ogni caso, non sarebbe un collo di bottiglia significativo rispetto al resto delle complesse operazioni che un browser deve eseguire per eseguire un corretto handshake TLS.
Sottovaluti le prestazioni di un albero di hash ben ottimizzato o di un albero radix. :)