Perché iterare 5200 volte quando si calcolano i numeri di sicurezza nel segnale?

Il commento non è spiegato molto bene, ma credo di aver determinato la matematica che ci sta dietro. Il numero di sicurezza è di 60 cifre a 10 basi, ma è creato in due metà a 30 cifre: una basata sul numero di telefono e sulla chiave pubblica e una basata sul numero di telefono e sulla chiave pubblica della persona con cui stai parlando.

Supponendo che un valore di entropia elevato venga convertito in un numero di 30 cifre senza inutile perdita di entropia, conterrà log ₂ (10 ³⁰ ) ≈ 99,66 bit di entropia, equivalenti a 99,66 "bit di sicurezza" (il che significa che un utente malintenzionato avrebbe il 50% di possibilità di abbinare quel numero di sicurezza dopo 2 hash ^99.66 / 2 = 2 ^98.66 ). L'iterazione di molte volte aumenta i bit di sicurezza (dal momento che aumenta il numero di operazioni hash per ciascuna prova effettuata dall'attaccante):

log ₂ (10 ³⁰ × 1024) ≈ 109,66

log ₂ (10 ³⁰ × 1400) ≈ 110.11

log ₂ (10 ³⁰ × 5200) ≈ 112,00

Questo è il numero di hash che un utente malintenzionato dovrebbe eseguire per abbinare un numero di sicurezza specifico, ma se l'utente malintenzionato voleva poter leggere i messaggi che gli hai inviato, avrebbe dovuto conoscere la chiave privata che corrisponde alla chiave pubblica utilizzata nell'hash. La generazione di keypair RSA è computazionalmente costosa, ma ECC è molto più veloce. Se la generazione di chiavi in mano è abbastanza veloce, ha senso iterare l'hash per aumentare il limite inferiore di un attacco su un numero di sicurezza.

Il numero di sicurezza è una derivazione dell'identificatore stabile e della chiave pubblica di un utente. I numeri di sicurezza sono calcolati per entrambe le persone in una conversazione.

Il vero codice importante è questo snipit

byte[] publicKey = getLogicalKeyBytes(unsortedIdentityKeys);  
byte[] hash = ByteUtil.combine(ByteUtil.shortToByteArray(FINGERPRINT_VERSION), publicKey, stableIdentifier.getBytes());  

for (int i=0;i<iterations;i++) {
        digest.update(hash);
        hash = digest.digest(publicKey);
      }

Quello che sta succedendo è che stiamo prendendo la versione dell'impronta digitale, la chiave pubblica e l'identificatore stabile come input iniziali e hashing che una volta con SHA-512. La seconda iterazione utilizza la chiave pubblica per l'hash appena creato, quindi la blocca una seconda volta.

Questo processo di aggiunta della chiave pubblica e ripetizione dell'hash continua per il numero di iterazioni indicate.

Perché dobbiamo fare più iterazioni rispetto al passato?

Ciò è dovuto a un problema fondamentale in caso di hashing. Qual è la possibilità di collisioni di hash.

Diciamo che sono un attaccante (Eve). Alice vuole parlare con Bob, quindi Signal invia la sua chiave pubblica a Bob, ma Eve intercetta la chiave pubblica e la sostituisce. Normalmente c'è un'indicazione che la chiave è cambiata e il Numero di sicurezza cambia.

SE Eve aveva abbastanza risorse da poter costruire una chiave pubblica che corrispondesse al numero di sicurezza. Per combattere questa minaccia, facciamo in modo che Eva debba trovare una collisione che si verifica dopo 5200 round di hashing, con l'aggiunta della stessa chiave ogni round.

Ciò diventa impossibile da computare poiché ogni round di hashing rende la ricerca di una collisione linearmente più dispendiosa dal punto di vista computazionale. Il numero di iterazioni attualmente selezionate di solito è calcolato sulla durata dell'attacco di questo stile in base alle risorse della minaccia percepita.

Non riesco a trovare alcun calcolo da Signal in merito al motivo specifico per cui hanno scelto 5200.