Sta perdendo l'hash della chiave di crittografia come un rischio per la sicurezza?

Se ogni entità, che vuole decrittografare il file, conosce solo alcune chiavi possibili, la soluzione più semplice è semplicemente provare tutte queste chiavi. Ciò presuppone che il meccanismo di crittografia includa un MAC , come dovrebbe comunque. Il MAC ti dirà se i dati sono validi o meno, il che intrappola sia le alterazioni dei dati (dannose o meno), sia il caso più semplice di usare una chiave sbagliata. La combinazione di MAC e crittografia è irta di pericoli e quindi sei incoraggiato ad usare una modalità che combina il MAC e la crittografia in modo sicuro ( EAX , GCM ...).

Se un'entità che desidera decrittografare i dati conosce molte chiavi di crittografia potenziali, provarle tutte potrebbero risultare inefficienti, nel qual caso può essere utile includere un identificatore di chiave nell'intestazione del file. L'hash della chiave non è male e non indurrà rischi aggiuntivi finché l'hash è "sufficientemente distinto" dall'elaborazione delle chiavi per la crittografia. Queste sono acque pericolose - qualificare correttamente questa proprietà, in modo scientifico, è già abbastanza difficile. Un metodo crittograficamente valido è il seguente: dalla chiave condivisa K , calcola SHA-256 ( K ). Questo produce 256 bit. Dividi questo in due parti: i primi 128 bit saranno il tuo "identificatore di chiave" (che può essere incluso nell'intestazione del file), mentre gli altri 128 bit saranno la chiave simmetrica effettivamente utilizzata per crittografare i dati.

La ricerca bruta delle chiavi AES a 128 bit per trovare una collisione SHA-1 non è più una preoccupazione di una ricerca di una forza bruta con decrittografia di prova. Se utilizzi qualcosa come PBKDF2 invece di un hash raw, puoi renderlo più difficile della decrittografia di prova.

(E infatti una collisione in quanto tale non aiuta un aggressore - se trova una chiave diversa con lo stesso hash, arriva a pubblicare un articolo sulla resistenza alla collisione SHA-1, perché con uno spazio di ricerca a 128 bit non dovrebbe accadere, ma non riescono a decodificare i dati.)

Hai un problema se qualcuno rompe SHA-1 così fondamentalmente possono trovare la chiave dall'hash (troncato) molto più facilmente di una ricerca di forza bruta (attacco preimage), ma in questo caso tutti usano SHA- 1 per le firme digitali. (E nell'improbabile eventualità che SHA-1 sia così rotto, SHA-256 probabilmente ha anche dei seri problemi.)

Hai anche un problema se ti interessi se un utente malintenzionato può stabilire quali messaggi sono stati crittografati con la stessa chiave e quali con chiavi diverse. Ad esempio, se sanno che una chiave particolare viene usata per messaggi importanti e possono vedere più messaggi usando quella chiave, potrebbero sapere che qualcosa di grande sta accadendo, anche se non possono dire cosa (cfr. link ). (Cambiare le chiavi pubbliche non sarà d'aiuto.)

Ci sono casi in cui la crittografia a chiave pubblica non è appropriata, ma senza sapere di più sul tuo caso d'uso, è difficile dire se questo è uno di questi.

Ad esempio, stai inviando le informazioni crittografate a un piccolo numero di destinatari o lotti? Così tanti che è poco pratico avere chiavi di sessione crittografate con tutte le loro chiavi pubbliche? Sapete a chi state inviando o distribuite la chiave segreta condivisa da qualcuno che non sia il mittente (quindi non potete sapere quali chiavi pubbliche usare, dovete avere fiducia che le persone giuste conoscono una chiave segreta - anche allora, perché non può esserci una chiave privata condivisa)? Vuoi essere in grado di ingrandire l'insieme di persone che possono leggerlo in un secondo momento quando potresti non avere accesso al messaggio originale (rivelando la chiave segreta ad altre persone, quando non puoi ri-cifrare con una nuova chiave pubblica )? Stai implicitamente supponendo che la conoscenza del segreto condiviso fornisca anche l'autenticità del mittente - in tal caso, sii molto cauto riguardo a ciò. (La risposta di Tom Leek si amplia ulteriormente. Vedi anche consigli sulla scelta di una modalità AE .)

Non mi piace affatto questa architettura. Come minimo, dovresti usare bcrypt con un fattore di lavoro molto elevato per produrre il tuo hash. Questo aggiunge anche salatura al tuo hash, che ti protegge da un attacco basato su una tabella arcobaleno. Penso davvero, però, che devi leggere di più sulla chiave pubblica.

Se il tuo caso d'uso richiede che tu non possa sapere in anticipo a chi stai inviando il messaggio, devi chiarire il tuo caso d'uso. La crittografia a chiave pubblica non impedisce in alcun modo a un nodo intermedio di inoltrarsi (si pensi all'e-mail crittografata con chiave pubblica). Hai solo bisogno di un protocollo incapsulante che trasporta il testo cifrato.

In particolare, sembra che tu pensi che la chiave pubblica richieda una negoziazione della chiave attiva come con TLS. Questo non è il caso. Dovresti guardare i protocolli come la posta elettronica protetta da PGP / GPG o S / MIME. PKI sembra la scelta migliore per la tua applicazione. Sfruttando i server delle chiavi pubblici ottieni revoca e distribuzione chiave sulla monetina di qualcun altro.

La condivisione delle chiavi è sempre stata dura da decifrare. Questo è il motivo per cui viene utilizzata la crittografia a chiave pubblica.

Il sistema che stai tentando di implementare userebbe un algoritmo di hashing (SHA-1) per verificare l'integrità della chiave condivisa. Supponi che domani qualcuno sia in grado di decifrare l'algoritmo di hash che stai usando, quindi il tuo sistema fallirà anche se l'algoritmo di crittografia che stai usando è abbastanza strong.

Secondo me non è una buona idea.

P.S. anche se sei al sicuro con SHA-1 (a meno che tu non sia una grande organizzazione) per favore passa a SHA-256. per dettagli vedi questo

Non penso che tu stia indebolendo catastroficamente la crittografia AES-128 rivelando l'hash SHA-1 troncato della chiave. Cioè, sotto gli attacchi pubblicamente noti contro i due in questa data.

"Inversione" dell'hash SHA-1 di un valore casuale a 128 bit è oggigiorno eseguito in modo più efficiente utilizzando gli attacchi del trade-time, come le tabelle arcobaleno. Ma troncare l'hash priva l'attaccante dei progressi fatti finora nella precomputazione.

[Era questo per cercare di rispondere alla tua domanda specifica. In generale, quando si crea il proprio schema crittografico, ci si trova in "acque pericolose", come un'altra risposta. Le tue ipotesi sulle abilità dell'attaccante sono realistiche? Quali altre proprietà di sicurezza ti interessano? Non lo troverai su Stack Exchange se la tua soluzione è protetta nel modo in cui ne hai bisogno. Trova una soluzione che abbia ricevuto un controllo sufficiente o che la tua soluzione sia esaminata da professionisti. Buona fortuna!]

Devo aggiungere che un altro modo per farlo [suggerito dal mio collega], (dato che l'hash della chiave è necessario solo per cercare la chiave effettiva) è dividere l'hash in due parti e crearle insieme e memorizzarle nel messaggio. In questo modo, nulla sulla chiave di crittografia è effettivamente trapelato. Ma se si conosce la chiave di crittografia, è banale da calcolare. Credo che questo sia ciò che chiamiamo un pad singolo.