AES è più facile da decifrare quando l'input è piccolo? [chiuso]

Question

AES è più facile da decifrare quando l'input è piccolo? [chiuso]

#1 da (3 voti)
#2 da (0 voti)

3

Diciamo che vuoi solo criptare un numero. Ad esempio, supponiamo che il numero possa essere qualsiasi double . Un doppio in C # e Java è 8 byte.

Se dovessi criptare un doppio usando AES:

var cypherText = AES.Encrypt(123d); // 8 bytes

sarebbe banale da decifrare? Altrimenti sarebbe almeno significativamente più facile da decifrare rispetto al testo cifrato da un input più ampio:

var largeText = GetDeclarationOfIndependence(); // 6760 ascii characters, so 6760 bytes
var cypherText = AES.Encrypt(largeText);

encryption aes

posta user875234 11.09.2018 - 13:50

fonte

2 risposte

0

Sì, se ...

Sei abbastanza stupido non per riempire i restanti 64 bit del blocco con dati casuali
L'attaccante sa che lo stai facendo (che in genere è un'ipotesi che dovresti fare secondo Kerckhoff).

La ragione è ovvia: AES opera su blocchi a 128 bit (= 16 byte) e se si riempiono solo 64 bit di payload (impostando i bit rimanenti a zero o qualche altra costante, o qualsiasi altra cosa), allora il il numero di uscite possibili è solo 2 ⁶⁴. Il che è fattibile solo per la forza bruta (e piuttosto facile da identificare, cerca un risultato in cui metà del blocco è uguale a PaddingValue ).

Assegnare una flebo dovrebbe fare il trucco. Mentre un solito "normale" IV in realtà non risolve il problema ^[1], se gli dai la giusta dimensione (8 byte) succede semplicemente a riempire il bit inutilizzati con casuale. Che è quello che devi fare.

^[1] Se anteponi un intero blocco come normalmente farebbe per un IV, allora il blocco con il payload ha ancora solo 64 bit non ovvi, nulla cambia, in realtà

risposta data 11.09.2018 - 16:15

fonte

Leggi altre domande sui tag encryption aes

Che tipo di hashing viene generalmente utilizzato nei moduli di accesso? Formato comune per l'invio di dati crittografati + IV?

score 3 · Accepted Answer

No, a meno che ...

Non dovrebbe essere possibile la "forza bruta" a meno che non si fornisca un oracolo per l'utilizzo da parte di un utente malintenzionato.

Un oracle in questo caso consente all'autore dell'attacco di inviare il testo in chiaro scelto nel proprio codice di crittografia e di ricevere l'output crittografato da controllare.

Se questo è il caso, è necessario salvaguardare i dati, preferibilmente impostando un vettore di inizializzazione per una modalità di cifratura a blocchi come CBC o CTR ( usa GCM se possibile ), e facendo in modo che la IV è scelta dall'oracolo (e non dall'attaccante).

Anche se dovresti davvero farlo comunque

Non penso che l'approccio di riempire i blocchi con dati casuali sarebbe molto efficace in un attacco contro un oracolo.

Potrebbe mitigare un attacco nel caso estremo estremo di avere solo 1 blocco di dati crittografati, ma non sarebbe altrettanto efficace quanto impostare correttamente un vettore di inizializzazione.

tl; dr No, a meno che non ci sia un oracolo da sfruttare per un utente malintenzionato. Se c'è, assicurati di impostare il vettore di inizializzazione (lato oracolo).