Ho implementato Diffie–Hellman key exchange in Java con alcuni grandi gruppi da RFC 3526. Il mio output è una gamma abbastanza ampia di byte. È sicuro utilizzare i primi 448 bit (56 byte) dell'output per una chiave blowfish? Devo trasformare i byte in qualche modo, o selezionare byte specifici per la chiave?Scelta di una chiave di crittografia dall'uscita Diffie-Hellman
Da un punto di vista teorico, no, non è sicuro. Non che potessi individuare un attacco reale; ma l'output di uno scambio di chiavi Diffie-Hellman è un elemento di un gruppo consistente in q elementi e offre la sicurezza sqrt (q) al massimo. Troncare parti della codifica di quell'elemento non sembra una buona idea ...
Il modo "corretto" è utilizzare una funzione di derivazione chiave unidirezionale. In parole semplici, elaborare l'output di Diffie-Hellman con una buona funzione di hash come SHA-256 e utilizzare il risultato dell'hash come chiave. Il tempo di hashing sarà trascurabile per quanto riguarda il passo Diffie-Hellman. Java include già implementazioni fini di SHA-256 e SHA-512 e, se si utilizza la compatibilità con implementazioni Java molto vecchie (ad esempio Microsoft JVM che era in arrivo con Internet Explorer 5.5), è possibile utilizzare un'implementazione Java indipendente di SHA-2 come quello in sphlib. O eventualmente reimplementarlo dalle specifiche (non è difficile): FIPS 180-3 (a PDF file).
Se hai bisogno di più di 128 bit per la tua chiave, significa che sei un viaggiatore del tempo dall'anno 2050 circa; 128 bit sono (molto) più che sufficienti per proteggerti per il momento, supponendo che tu usi uno schema di crittografia simmetrico adeguato.
A proposito: Blowfish non è più raccomandato. Ha blocchi a 64 bit, il che implica problemi quando la lunghezza dei dati crittografati raggiunge alcuni gigabyte, una dimensione che non è così grande al giorno d'oggi. Sarebbe meglio usare un codice a blocchi a 128 bit come lo AES. Inoltre, in qualsiasi sistema di crittografia simmetrica serio è necessario un controllo di integrità con chiave. Questo può essere fatto con un MAC (Message Authentication Code) come HMAC, esso stesso costruito su una funzione hash (quindi ancora una volta, facile da implementare, e c'è un'implementazione Java in sphlib). O, ancora meglio, usa l'AES in una modalità combinata di crittografia/MAC che gestirà i dettagli più complicati per te (perché l'uso di un codice a blocchi è correttamente non facile); look CWC e GCM (entrambi sono privi di brevetti, quest'ultimo è stato approvato dal NIST).
La soluzione proposta dipende dal fatto che i bit più significativi di uno scambio Diffie-Hellman siano fondamentali. Ci sono alcuni piccoli risultati noti che mostrano che i bit più significativi sono imprevedibili, ma non sono a conoscenza di un documento sufficientemente forte da mostrare che il tuo approccio è corretto.
Tuttavia, ci sono diverse proposte per una derivazione di chiave da chiavi Diffie-Hellman. E.g. una bella carta è NIST SP 800-135. Finora questa è solo una bozza e può essere trovata here. Tuttavia, rivede alcuni standard esistenti. Ovviamente, usare uno standard è sempre preferibile per svilupparlo da solo.
Mentre la proposta di Thomas Pornin sembra ragionevole, è comunque una soluzione ad hoc. E per essere sicuri non dovresti usarlo. Piuttosto, userei qualcosa che è stato analizzato (ad esempio lo schema di derivazione chiave utilizzato in TLS versione 1.2).
Molto informativo. Sto usando la crittografia per il traffico UDP con dimensioni del pacchetto abbastanza piccole. Da quello che ho letto, Blowfish sembrava paragonabile ad AES, ma molto più veloce. Ho trascurato i MAC in passato, ma ora darò un'occhiata più da vicino. –
Per qualsiasi cosa relativa alla velocità, è necessario misurare.Blowfish era considerato veloce rispetto a 3DES, circa 12 anni fa; ma AES è molto più veloce di 3DES. Blowfish è anche noto per avere un programma di chiavi lente (cambiare una nuova chiave è costoso). Dal punto di vista della sicurezza, AES è molto meglio, se non altro perché è stato esaminato da molti altri crittografi. Il designer Blowfish ha persino creato una nuova versione, chiamata Twofish, che era un candidato per diventare l'AES (ma Rijndael è stato scelto, invece, ed è diventato AES). –
Il modo corretto è utilizzare uno standard, non progettare autonomamente schemi crittografici. – Accipitridae