PBKDF2 utilizzato per generare una chiave di crittografia: lungo segreto condiviso (password) vs conteggio iterazioni

La linea di macchine AS / 400 ha una lunga storia. Normalmente usano la CPU della famiglia PowerPC / POWER, ma i primi modelli sono iniziati con CPU con clock a 55 MHz, che non si può pretendere di essere veloci ... Ciò potrebbe spiegare le pessime prestazioni che si ottengono. O forse c'era qualche problema sottile nel tuo processo di porting. Ad esempio, lo srotolamento del loop aggressivo può far sì che un codice di funzione superi la cache L1, il che può uccidere le prestazioni in grande tempo (ho già assistito a un rallentamento di 50 volte per tali casi).

In ogni caso, le iterazioni in PBKDF2 sono pensate per compensare l'entropia relativamente bassa della password di input (perché la password è una password , adatta a un cervello umano). Se riesci a far sì che la password abbia un'alta entropia, otterrai sicurezza con un conteggio iterato basso.

(Ricorda che l'entropia non è la lunghezza. Entropia è casualità .)

Come dice il nome, una chiave di derivazione basata su password (PBKDF) viene utilizzata per ottenere una chiave di crittografia da una password . Le password sono generalmente brevi (bassa entropia) e la forzatura bruta può essere eseguita in tempi ragionevoli. Il PBKDF quindi ostacolerà la forzatura bruta usando un sacco di tempo per ipotesi.

Sembra che tu abbia il controllo sulla chiave (non l'utente sta scegliendo una password), in questo caso è sicuro fare a meno del PBKDF e usare direttamente la chiave segreta. Se il tuo algoritmo, ad es. si aspetta una chiave di 32 byte, questa chiave ha un'alta entropia e non può essere forzata bruta in tempi ragionevoli. Tieni presente che quei 32 byte non sono un testo alfanumerico, ma è come un array di 32 byte casuali.

EDIT:

Dal tuo commento vedo che è davvero una password, quindi il PBKDF è la strada giusta da percorrere. In realtà è corretto che una lunga password (una password con un'alta entropia) consentirebbe di diminuire il fattore di costo, anche se la difficoltà è quella di garantire che l'utente scelga davvero una password così strong. Le solite regole non sono un buon indicatore, perché una password come Password2014 o proverbi noti riempie la maggior parte delle regole, ma non sono password sicure. Una via d'uscita sarebbe che l'applicazione genera autonomamente password complesse e accetta solo password di questo modulo.

Is there some kind of rule, like "adding n characters to the password is somewhat equivalent increasing the number of iterations (c) of x?

Il compromesso tra forza della password e conteggio delle iterazioni è id: log, dove id è l'identità e log è il logaritmo. Quindi 1000 iterazioni significherebbero circa 10 bit di forza aggiuntiva per la password. Un milione di iterazioni significherebbe 20 bit aggiuntivi. Tuttavia, non esiste una strong relazione 1: 1 tra il numero di caratteri di una password e la sua forza in bit, solo per le password veramente casuali.

PBKDF è una pessima soluzione per un problema che altrimenti sarebbe anche peggio. Aggiunge solo logaritmicamente alla forza. Di solito PBDKF non crea questo carico generale in quanto anche per i servizi di grandi dimensioni il numero di persone che accedono per un dato momento è piccolo rispetto al numero di utenti totali. Ma nel tuo caso si applica chiaramente il problema di carico PBDKF.