Crittografia AES di 16 byte senza sale

Question

Quanto è sicuro crittografare 16 byte di dati come un unico blocco con AES? Nessun sale/IV, nessuna modalità di funzionamento, milioni di diversi blocchi da 16 byte crittografati. Non ne so abbastanza di cripto ma questo mi odora.

Modifica: per fornire maggiori dettagli, non si tratta di crittografare un messaggio ma una colonna della tabella del database in cui la lunghezza del testo normale è di 16 byte. I dati non sono totalmente casuali (i primi 8 byte saranno spesso uguali) e c'è un checksum per identificare una decifrazione corretta.

Mi trovo in un incontro con i ragazzi che propongono questa settimana e, se c'è un problema, apprezzerei molto alcune indicazioni su come fare riferimento al materiale con cui posso dimostrare che il design è insicuro. Non conosco completamente il sistema, ma penso che questo potrebbe richiedere un importante riprogettazione per aggirare, quindi è probabile che ci sia molta resistenza. La maggior parte delle persone (e del potere) coinvolte sono sul lato business dove la motivazione è ottenere un sistema funzionante ...

Answer 1

ECB non è sicuro per l'uso generale. Un dato testo in chiaro cripta sempre allo stesso testo cifrato, quindi i pattern possono essere rivelati. Tuttavia, ci sono casi speciali in cui è sicuro, e questa applicazione potrebbe essere una di queste.

Citazioni Crittografia applicata, seconda edizione pag. 190, per quanto riguarda la modalità della BCE per un cifrario a blocchi:

Sul lato positivo, non c'è sicurezza rischio crittografia dei messaggi multipli con la stessa chiave. In effetti, ogni blocco può essere visto come un messaggio separato crittografato con la stessa chiave.

Più tardi (. P 208), Schneier afferma:

Se la semplicità e la velocità sono le vostre principali preoccupazioni , BCE è il più semplice e più veloce per modalità utilizzare un cifrario a blocchi. Lo è anche il più debole.Oltre ad essere vulnerabile agli attacchi di riproduzione, un algoritmo in modalità ECB è il più semplice in cryptanalyze. Non consiglio l'ECB per la crittografia dei messaggi.

Per la crittografia di dati casuali, come ad esempio , l'ECB è una buona modalità da utilizzare. Poiché i dati sono brevi e casuali, nessuna delle carenze della materia BCE per questa applicazione.

Il prefisso comune e cifra di controllo nel tuo caso non produrrà testo cifrato comune. Ciò accade solo se un intero blocco di testo in chiaro è duplicato . Da quello che hai descritto, la tua applicazione potrebbe essere adatta per ECB — specialmente se ogni valore di testo in chiaro, nel suo insieme, è unico.

Answer 2

Senza un sale, noto anche come vettore di inizializzazione o IV, la sicurezza del testo cifrato (e, credo, anche la chiave) è notevolmente ridotta. Un potenziale aggressore sarà molto più facilmente in grado di distinguere pattern ripetuti nel testo crittografato. IIRC era lo stesso errore di base che Microsoft ha commesso durante l'aggiornamento dello schema di crittografia di MS Office.

Answer 3

In termini di crittografia, questo è insicuro solo se l'utente malintenzionato conosce l'algoritmo specifico e IV.

Viene fornita una certa ipotesi: una volta decodificato, l'utente malintenzionato sa come appaiono i dati per sapere che il tentativo di decrittografia ha avuto esito positivo? per esempio. Esiste un MD5, CRC o qualche forma di checksum in grado di verificare un tentativo di decodifica riuscito? Se è così, dai all'attentatore un modo per convalidare il tentativo.

Ma in termini di hacking, ci sono ancora 2^128 combinazioni di chiavi (per cifrare a 128 bit), che è altrettanto sicuro di usare la stessa chiave su terabyte di dati. La modalità di funzionamento è irrilevante poiché 16 byte di dati sono solo un blocco, quindi non si applica la cifratura a blocchi di codice (CBC).

Tuttavia, si applica il sale IV e tale valore dovrebbe essere altrettanto segreto della chiave stessa. Una tabella arcobaleno può essere utilizzata per accelerare un attacco di forza bruta su cifrari che non usano un sale; questo è il tuo anello debole.

Answer 4

AES è piuttosto forte contro gli attacchi con solo testo cifrato. Tuttavia, la crittografia di molti testi in chiaro con la stessa chiave rende il sistema più vulnerabile agli attacchi in testo normale e in chiaro.

Detto questo, se la chiave di crittografia è casuale, e se i testi in chiaro sono apparentemente casuali, potresti essere ancora al sicuro. Ma sicuramente prenderei in considerazione l'utilizzo di chiavi diverse.

D'altra parte, se i testi in chiaro sono correlati l'uno all'altro e/o non apparentemente casuali, la BCE non è affatto sicura.

Answer 5

Non sono a conoscenza di punti deboli in AES per i messaggi brevi. L'algoritmo dovrebbe essere molto felice.

di prendere per il vostro incontro si vuole:.

1) Un modello di minaccia (che può vedere cosa, quando e cosa succede quando lasciano o diventare un "cattivo ragazzo)

2) Alcuni casi d'uso dal tuo modello di minaccia

Con questo dovresti essere in grado di determinare se hai veramente bisogno di sale AES e, la crittografia protegge davvero il valore nella colonna se puoi derivarlo altrove facendo l'uso di AES kinda inutile Infine, ponete la domanda: "La chiave è veramente più sicura dei dati?" Ho visto schemi come questo in cui la chiave aveva le stesse dimensioni di he data (where size = "kinda small") ed era accessibile quanto i dati che stava proteggendo. Sì, ti comprerà alcune ore mentre l'aggressore capisce cosa diavolo hai fatto, ma non ti dà molto in termini di sicurezza solida.

La speranza che ti aiuta e ti dà qualcosa da masticare. Non conoscendo la tua particolare posizione, è difficile personalizzare la risposta. :)