Stai sbagliando. Non nella divisione o qualsiasi altra cosa; ma nel pensiero . La crittografia AES, se eseguita correttamente, non sarà "incrinata". AES è il pezzo più robusto del tuo sistema; questa è l'ultima parte di cui dovresti preoccuparti.

Ciò che fornisce la crittografia AES è una funzionalità molto specifica: utilizzando una determinata chiave K , trasforma un pezzo di dati (il "testo in chiaro") in qualcosa che è illeggibile (il "testo cifrato") < em> tranne a chi conosce K , perché sapere K consente di invertire la trasformazione. Finché K rimane sconosciuto agli aggressori, i dati crittografati sono al sicuro. Se K è noto agli attaccanti, allora hanno vinto e nessuna quantità di spaccare, scambiare o danzare intorno al fuoco mentre cantano la gloria del Grande Spirito, ti salverà.

AES utilizza chiavi di 128, 192 o 256 bit. Ci sono così tante possibili chiavi che la probabilità che un attaccante comprometta la chiave attraverso la pura fortuna è infinitesimale. Le chiavi a 128 bit sono sufficienti per questo; le chiavi più grandi non sono pensate per aumentare la sicurezza ma per affermare il tuo stato di maschio alfa tra i tuoi colleghi sviluppatori.

Se hai davvero bisogno di impegnarti in elaborati rituali di mescolanza di dati in modo che, ad esempio, il tuo capo abbia l'impressione che "la sicurezza stia accadendo" e tu non stia sviando, allora puoi anche farlo correttamente. Non spaccare; invece, data una sequenza di byte C (la stringa crittografata), genera una sequenza di byte casuali D della stessa lunghezza; quindi "dividi" C in due condivisioni C ₁ = C XOR D , e C ₂ = D . Per assemblare le condivisioni, basta unirle a XOR: succede così che C ₁ XOR C ₂ = C . Questo tipo di divisione è dimostrabilmente sicuro (un utente malintenzionato che impara C ₁ o C ₂ , ma non entrambi, impara esattamente niente , in un senso informativo-teorico , che è buono come qualsiasi cripto può ottenere). Ovviamente, a patto che non ci siano problemi (devi generare un D strongmente casuale e generarne uno nuovo ogni volta che hai una stringa da "dividere").

Dovresti preoccuparti dell'archiviazione sicura della chiave AES, non della scomposizione dei dati. Se la chiave è compromessa, in realtà non farà alcuna differenza rispetto a ciò che hai fatto con i dati perché principio di Kerckhoffs .

Modificato per aggiungere: In particolare, non è necessario memorizzare la chiave AES nello stesso database che contiene i dati crittografati poiché un compromesso del database produrrà sia la chiave che i dati. I compromessi del database remoto, e.g. tramite l'iniezione SQL, sono talvolta possibili anche quando l'intero sistema operativo non è compromesso. La memorizzazione della chiave altrove fa parte della difesa in profondità. Idealmente verrebbe memorizzato utilizzando un modulo di sicurezza hardware (HSM), ma compilato in un programma o anche come file nel file system è di gran lunga migliore rispetto all'archiviazione nel database.

Posso suggerire di ripensare al tuo approccio a questo problema. Dove stai conservando i dati? Se si trova in un database, la maggior parte dei database ha la capacità di crittografare i dati a riposo in modo abbastanza sicuro. I dati devono spostarsi su un canale non sicuro? Esamina l'HTTPS o l'FTP sicuro. Non scherzare con Crypto a meno che tu non abbia assolutamente anche tu. È estremamente facile sbagliare.