Funzione hash espandibile / inversa

L'hashing è una manipolazione algoritmica dei dati. Una funzione di hashing crittografica è una funzione unidirezionale con una dimensione di output fissa indipendentemente dalle dimensioni dell'input.

Sembra che tu stia parlando di aumentare la sicurezza usando un diverso tipo di funzione di hash, quindi no ... nessun hash crittografico corrisponde a proprietà che non ho descritto sopra. Per altri tipi di hashing (in particolare per quanto riguarda le strutture dati), vedi link .

Altrimenti, la risposta è no e l'allungamento variabile degli input non sarebbe un miglioramento in quanto è impossibile generare più entropia senza aggiungere altro input. Non è possibile aggiungere più input poiché la funzione di hash monodirezionale deve essere ripetibile per essere utile.

Non c'è alcun guadagno di sicurezza, per l'hashing della password, per avere un output hash più lungo. L'utente malintenzionato cerca "password plausibili" finché non viene trovata una corrispondenza con il valore hash memorizzato. Lo spazio delle password che l'utente malintenzionato proverà (indipendentemente da come le tenta esattamente, ad esempio con una tabella arcobaleno) sarà molto piccolo, in termini assoluti (meno di 2 ⁸⁰ ). Corrispondentemente, l'attaccante ha solo bisogno di lavorare sui primi 80 bit del valore hash, anche se hai archiviato 2000 bit di output: 80 bit sono sufficienti, per l'attaccante, perché non otterrà molti "falsi positivi".

Il meme "più grande è meglio" è strong nel settore, ma in crittografia è piuttosto sbagliato.

Detto questo, è possibile generare un output lungo da un input piccolo; questo è il principio di funzionamento della cifratura dei flussi . Un modo semplice consiste nell'hash la password con una normale funzione di hashing della password (vedere questo ) e quindi utilizzare l'output hash come chiave per un codice di streaming (ad esempio uno dei questi ). C'era una funzione di hash che combinava entrambi i passaggi, chiamata Panama (risultò essere debole, ma non per questo motivo, alcuni dei principi di Panama sono stati riutilizzati nel nuovo SHA-3, alias Keccak ).

Per aggiungere alla risposta di Jeff Ferland, in particolare non renderebbe più difficile la costruzione di tabelle arcobaleno, a livello computazionale algoritmi che sono computazionalmente equivalenti. Richiederebbe solo spazio di archiviazione aggiuntivo per l'output delle tabelle arcobaleno. Tuttavia, questo è insignificante dal punto di vista della sicurezza perché le tabelle rainbox sono diventate in gran parte obsolete con l'uso diffuso dell'hashed salato e la potenza di calcolo relativamente economica a cui ora possiamo accedere a causa della legge di Moore e delle moderne GPU.

Quindi, se ho bisogno di calcolare tutti gli hash possibili per un dato input + un determinato salt in ogni caso, la dimensione dell'output è sostanzialmente irrilevante.

Qualcosa che corrisponde strettamente a questa descrizione è KDF o estensione del codice , ad es. PKCS # 5 PBKDF2 . L'intento di tale schema (in assenza di uno schema di hashing della password più adatto come bcrypt ) è quello di rendere forzatura di una password scelta dall'utente (attacco basato sul dizionario) più costosa di un attacco brute-force completo sull'intero dominio di input.

Sebbene l'output del KDF possa non avere sempre più bit di una password arbitraria scelta dall'utente, è più "opaco", e può essere più lungo della lunghezza minima della password (sebbene non possa aggiungere entropia, come notato in La risposta di Jeff Federland).

La dimensione dell'output dell'hash non è un buon indicatore di resistenza agli attacchi del rainbow-table, salt è .

Non sei sicuro di cosa stai ricevendo. Esistono due categorie principali di usi di un hash crittografico.

1. Per verificare l'integrità di un file di grandi dimensioni con un checksum consegnato in modo sicuro. Ad esempio, il checksum viene consegnato tramite un canale sicuro (ad esempio https da un sito conosciuto) mentre il file viene trasmesso tramite un canale non protetto, ma confrontato con il checksum alla fine e

2. Per autenticare l'identità di un utente tramite una password senza memorizzare la password in chiaro in un database. Cioè se la mia password è Correct Horse Battery Staple , memorizzerei $2a$12$5vc0XINA0MiPvgE3ffLnaOVGqrMeskLKjFvIg4BKryq3v5PXt1oIi come hash di bcrypt a 184 bit nel mio database (con un sale di 128 bit). Quando un utente che conosce la password segreta accede, il server confronta l'hash generato dalla password (e sale) con l'hash memorizzato e li lascia solo se corrispondono.

La possibilità che un attaccante indovini casualmente l'hash in una prova equivale a 1 possibilità in 2 ^{{lunghezza bit dell'hash}} . Quindi, per un hash a 256 bit, un utente malintenzionato ha 1 su 115792089237316195423570985008687907853269984665640564039457584007913129639936 possibilità di indovinare casualmente l'hash in un tentativo (e anche se gli permetti di provare un miliardo di hash al secondo per un miliardo di anni su un miliardo di computer, avrebbero solo provato ~ 10 ³⁴ password e la loro possibilità di crackare con successo la password è solo di circa 1 su 10 ⁴² (ad esempio, la possibilità di vincere powerball è di circa 1 su 10 ^ 8; quindi è simile alla tua possibilità di giocare a powerball per cinque volte consecutive e vincere il jackpot ognuna di queste cinque volte. E ancora, questo era per un hash a 256 bit, un hash 184 o 512 o 1024 bit sarebbe stato esponenzialmente più strong.

Ora, se disponi di un hash con dimensioni non fisse, ciò sembra controproducente. Per esempio,. trasferisci un file da 1 GB su Internet, vuoi veramente calcolare un checksum su un checksum della stessa dimensione o più grande? Inoltre, ciò potrebbe far filtrare le informazioni sui dati che sono stati sottoposti a hash. Ad esempio, se la tua funzione di hashing aumenta di due byte per ogni byte aggiunto, puoi trovare la lunghezza della password originale; che potrebbe essere utile per trovare rapidamente le password più corte per provare la forza bruta tramite la ricerca nel dizionario delle password di quella lunghezza. E ancora, 2 ²⁵⁶ è già abbastanza strong da superare qualsiasi attaccante possibile, non c'è bisogno di provare a usare un hash della dimensione di 1 GB per impedire a un attaccante che può fare 2 ^8589934592 tentativi, in quanto non esiste un modo fattibile per rendere 2 ²⁵⁶ anche con ipotesi molto irragionevoli.

Detto questo, espansione chiave - che sta prendendo una chiave pseudo-casuale di una data lunghezza relativamente breve (come 128-bit / 256-bit) e quindi usandola come "seme" "creare molte più chiavi pseudo-casuali (di lunghezza totale molto più lunga della chiave originale) è comunemente usato per molti scopi crittografici. Ad esempio, in AES128, una chiave a 128 bit viene espansa in 11 tasti rotondi ciascuno di 128 bit (ad es. 1408 bit in totale) utilizzati in ogni round del processo di crittografia AES.

Allo stesso modo, una cifratura di flusso è spesso sostanzialmente equivalente a un'espansione chiave; ad esempio, puoi costruire un codice di flusso da un codice a blocchi che opera in modalità contatore. Fondamentalmente, dite di avere un codice a blocchi (come AES256) in cui prendete un blocco di dati P a 256 bit, una chiave K a 256 bit, e potete ottenere un testo cifrato da una funzione di crittografia come C = E (K, P). Bene, se inizi con un P casuale a 256bit, puoi creare un flusso pseudocasuale di lunghezza molto lunga usando C0 = E (K, P) per i primi 256 bit, C1 = E (K, P + 1) per i successivi 256 bit , C2 = E (K + 2) per i successivi 256 bit. E puoi farlo per avere un flusso pseudocasuale che puoi XOR con il tuo messaggio. E puoi farlo per molti terabyte di dati prima che gli attacchi diventino fattibili dal punto di vista computazionale.

Tuttavia, non chiamerei l'espansione chiave / codice di streaming l'opposto di un hash. Sono solo cose diverse.