Proteggere gli hash delle stringhe corte

Penso che sì, è ancora sicuro, a seconda di come funziona l'hashing.

Non stai davvero parlando di un valore salino, dal momento che è sconosciuto. Lo scenario che descrivi si adatta a un IMO MAC migliore. I MAC richiedono i dati di input (il tuo singolo carattere) e un segreto (il tuo "sale" sconosciuto) e sono progettati per essere sicuri nonostante i dati di input in chiaro siano noti (dato che sono solitamente usati per autenticare i messaggi, dove sia il MAC che il testo in chiaro messaggio è noto).

Per essere sicuro contro gli attacchi, non puoi semplicemente usare un semplice hash, come

value = sha256(character || secret)

Questo non sarebbe sicuro. Ma se usi una primitiva come HMAC, dovrebbe essere:

mac = hmac_sha256(character, secret)

I tuoi requisiti, se ho capito bene, sono che dovrebbe essere impossibile per qualcuno senza il segreto determinare, dato

mac1 = hmac_sha256('0', secret)
mac2 = hmac_sha256('1', secret)
...
mac62 = hmac_sha256('z', secret)

che mac va con quale carattere di input e qual è il segreto.

I MAC garantiscono che con un dato input, come '0' e mac1, non c'è migliore attacco al segreto della forza bruta, anche se il segreto viene riutilizzato molte volte. Quindi il tuo segreto è sicuro.

La domanda che rimane è se puoi determinare quale carattere di input appartiene a mac1, mac2 ecc se non sei in possesso del segreto.

I penso che sia ugualmente impossibile, ma non riesco a vedere come provare l'equivalenza di quello con l'integrità del messaggio che garantisce i MAC, quindi anche se non penso che lo sia, potrei si sbaglia.

Ho alcune ragioni per le mie convinzioni:

Idealmente, per le funzioni di hash, se si modifica un singolo bit nel messaggio, questo dovrebbe influenzare tutti i bit del valore di hash. Se capisco il modo in cui hmacs è calcolato correttamente, allora questo vale anche per il segreto, ad es. il segreto influenza ogni singolo bit nell'output di mac. Quindi se ci fosse un modo per determinare quale mac appartenesse a quale input senza il segreto, penso che significherebbe che hmac sta perdendo informazioni sul segreto, e quindi dovrebbe esistere un metodo migliore del metodo brute-force per attaccare il segreto.

In realtà dovresti chiedere ad un crittografo, quindi crypto.stackexchange.com potrebbe essere il posto migliore per ottenere una buona risposta.

Se comprendo correttamente i tuoi requisiti,

• Dovrebbe essere impossibile per un utente malintenzionato (senza la chiave segreta) che vede tutti i 62 messaggi per indovinare quale personaggio Alice ha digitato per un particolare messaggio rispetto alla probabilità 1/62 di un utente malintenzionato che non ha visto nessuno dei i messaggi.
• Dovrebbe essere impossibile per un utente malintenzionato (senza la chiave segreta) che vede tutti i 62 messaggi per indovinare la chiave segreta.
• Dovrebbe essere impossibile per un utente malintenzionato senza la chiave segreta, che ha visto fino a 60 messaggi, calcolare in modo attivo il MAC corretto per entrambe le rimanenti 2 lettere per le quali l'utente malintenzionato non ha ancora visto il MAC.

Se comprendo correttamente l'algoritmo proposto,

• La macchina di Alice ha una singola chiave segreta che presumiamo che l'autore dell'attacco non non avere.
• Ogni volta che Alice digita un carattere alfanumerico (a-z, A-Z, 0-9), la macchina usa una funzione di hash crittograficamente sicura per annullare la concatenazione di quel personaggio con quella chiave segreta, e invia il codice di autenticazione dei messaggi risultante a Bob.
• Alice non ripete mai un personaggio (invia al massimo 62 messaggi con questa particolare chiave segreta).
• Bob scarta tutte le ripetizioni.
• Alice non invia il messaggio successivo fino a quando non apprende che Bob ha ricevuto l'ultimo messaggio. (Va bene che il computer di Alice continui a inviare nuovamente il pacchetto contenente quel messaggio finché non riceve la conferma dal computer di Bob).

Questo algoritmo mi sembra al sicuro.

(Non userei il termine "sale" in questo algoritmo per descrivere quella chiave segreta. Un sale crittografico è, per definizione, qualcosa che assumiamo l'hacker sa, e di solito viene generato casualmente per ogni oggetto. Nessuno dei due è vero per questo algoritmo. ).

Poiché la stringa hash (un singolo carattere concatenato con la chiave segreta) ha una lunghezza fissa, sembra che qualsiasi hash crittograficamente sicuro sarà sufficiente in questo algoritmo - non è vulnerabile al attacco dell'estensione della lunghezza che difende HMAC .

Se modifichiamo l'algoritmo in modo che Bob non scarti le ripetizioni, rende il sistema modificato vulnerabile a un utente malintenzionato attivo utilizzando un attacco di riproduzione .

Se modifichiamo l'algoritmo per consentire ad Alice di ripetere un carattere, poiché il processo è deterministico, una Eva intercettatrice può facilmente rilevare quando Alice ripete un personaggio, perché entrambe le volte Alice digita quel personaggio, produce esattamente lo stesso MAC. (Questo rende vulnerabile il sistema modificato attacco con testo normale ). Un vero sale, generato in modo nuovo e casuale per ciascun messaggio, incluso nell'input della funzione hash, e anche trasmesso in chiaro con quel messaggio, potrebbe essere usato per rendere il processo non deterministico abbastanza da difendersi da questo attacco.

Se modifichiamo l'algoritmo in modo che Alice invii più messaggi prima che Bob confermi la ricezione, il sistema modificato è vulnerabile a un man-in-the-middle attivo che riordina i messaggi in sospeso.

Hai effettivamente un codice di sostituzione e l'algoritmo non è più sicuro sostituendo un singolo carattere con un hash invece di un altro singolo personaggio. Se qualcuno deve decifrare un singolo carattere o un hash in isolamento, lo si potrebbe considerare sicuro , tuttavia gli usi ripetuti probabilmente consentirebbero l'analisi della frequenza e altri attacchi per recuperare il testo in chiaro.