crittografia AES di 16 byte senza sale

Question

Quanto è sicuro per crittografare 16 byte di dati in un unico blocco con AES? No sale / IV, nessuna modalità di funzionamento, milioni di diversi blocchi di 16 byte cifrati. Non so abbastanza di crypto ma questo odori a me.

Modifica: per dare un po 'più in dettaglio non si tratta di crittografia di un messaggio, ma una colonna della tabella di database in cui la lunghezza di testo sembra essere 16 byte. I dati non è del tutto casuale (i primi 8 byte saranno spesso lo stesso) e v'è una somma di controllo per identificare un decrittografia successo.

Io vado in un incontro con i ragazzi che propongono questo la prossima settimana e, se c'è un problema, apprezzo molto alcune indicazioni per fare riferimento a materiale con cui posso dimostrare che il design è insicuro. Io non sono del tutto familiarità con il sistema, ma credo che questo potrebbe richiedere una riprogettazione importante per andare in giro quindi non è probabile che sia un sacco di resistenza. La maggior parte delle persone (e il potere) coinvolti si trovano sul lato business in cui la motivazione è quello di ottenere un sistema di lavoro ...

Answer 1

BCE non è sicuro per uso generale. Un dato testo semplice cripta sempre allo stesso testo cifrato, in modo da modelli possono essere rivelati. Tuttavia, ci sono casi particolari in cui è sicuro, e questa applicazione possono essere uno di loro.

Citando Applied Cryptography, seconda edizione pag. 190, per quanto riguarda la modalità della BCE per un cifrario a blocchi:

  

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

(Pag. 208)

In seguito, Schneier afferma:

  

Se la semplicità e la velocità sono le tue principali   preoccupazioni, BCE è il più semplice e   la modalità più veloce per usare un cifrario a blocchi. esso   è anche il più debole. Oltre ad essere   vulnerabile a un replay attacchi, un   algoritmo in modalità BCE è il più facile   a cryptanalyze. Non consiglio BCE   per la crittografia dei messaggi.

     

Per la crittografia dei dati casuali, come ad esempio   altri tasti, BCE è una buona modalità per l'uso.    Poiché i dati è breve e casuale,   nessuno dei difetti della materia BCE   per questa applicazione.

Il prefisso comune e cifra di controllo nel tuo caso non produrrà testo cifrato comune. Questo accade solo se un intero blocco di testo in chiaro è duplicato. Da quello che hai descritto, l'applicazione può essere una buona misura per ECB soprattutto, se ogni valore di testo, nel suo complesso, è unico nel suo genere.

Answer 2

Senza un sale, noto anche come il vettore di inizializzazione o IV, la sicurezza del cifrato (e, credo, la chiave, nonché) è notevolmente ridotto. Un potenziale aggressore sarà molto più facilmente in grado di distinguere pattern ripetuti nel testo cifrato. IIRC questo è stato lo stesso errore di base che Microsoft ha fatto quando si aggiorna lo schema di crittografia di MS Office.

Answer 3

AES è piuttosto forte contro gli attacchi testo cifrato solo. Tuttavia, la crittografia di un sacco di testi in chiaro con la stessa chiave rende il sistema più vulnerabile agli attacchi known-plaintext e scelti in chiaro.

Detto questo, se la chiave di crittografia è casuale, e se i testi in chiaro sono apparentemente casuale, si potrebbe ancora essere al sicuro. Ma vorrei sicuramente considerare l'utilizzo di chiavi diverse.

D'altra parte, se i testi in chiaro sono legati gli uni agli altri e / o non apparentemente casuale, BCE non è affatto sicuro.

Answer 4

Non sono a conoscenza di eventuali carenze AES per i messaggi brevi. L'algoritmo dovrebbe essere felice un sacco.

Per prendere alla riunione 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 vostro modello di minaccia.

Con questo si dovrebbe essere in grado di determinare se si ha realmente bisogno di sale e AES, fa la crittografia davvero proteggere il valore della colonna se si può ricavare che fare altrove l'uso di AES po 'inutile. Infine, porre la domanda, "è la chiave realmente più sicuro che i dati?" Ho visto programmi come questo, dove la chiave era la stessa dimensione dei dati (dove size = "un po 'piccola") ed era altrettanto accessibile come i dati che stava proteggendo. Sì, comprerà un paio di ore, mentre l'attaccante capisce cosa diavolo hai fatto, ma non ti dà molto in termini di sicurezza solido.

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

Answer 5

In termini di crittografia, questo è sicuro solo se l'attaccante conosce l'algoritmo specifico e IV.

Una certa ipotesi è fatta: una volta decifrati, sarà l'attaccante sapere che i dati sembra di conoscere il tentativo di decrittazione ha avuto successo? per esempio. C'è un MD5, CRC, o qualche forma di checksum in grado di verificare un tentativo di decrittazione di successo? Se è così, si dà all'attaccante un modo per convalidare il tentativo.

Ma in termini di hacking, c'è ancora 2 ^ 128 combinazioni di tasti (per 128 bit), che è altrettanto sicuro come utilizzando la stessa chiave su terabyte di dati. Modalità di funzionamento non è pertinente 16 byte di dati è soltanto un blocco, in modo da cipher-block-chaining (CBC) non si applica.

Tuttavia, il sale IV si applica e che valore dovrebbe essere altrettanto segreta come la chiave stessa. Un tavolo arcobaleno può essere utilizzata per accelerare un attacco di forza bruta cifrari non utilizzano un sale; questo è il vostro punto debole.