Lo estás haciendo mal. No en la división o lo que sea; pero en el pensamiento . El cifrado AES, si se hace correctamente, no será "crackeado". AES es la pieza más robusta de su sistema; Esta es la última parte de la que debería preocuparse.

Lo que proporciona el cifrado AES es una funcionalidad muy específica: al utilizar una clave K determinada, transforma una parte de los datos (el "texto simple") en algo que es ilegible (el "texto cifrado") < em> excepto para aquellos que saben K , porque conocer K permite revertir la transformación. Mientras K permanezca desconocido para los atacantes, los datos cifrados están seguros. Si los atacantes conocen a K , entonces han ganado, y ninguna cantidad de división, intercambio o baile alrededor de un fuego mientras cantan la gloria del Gran Espíritu, te salvará.

AES utiliza claves de 128, 192 o 256 bits. Hay tantas claves posibles que la probabilidad de que un atacante comprometa la clave a través de la suerte pura es infinitesimal. Las claves de 128 bits son suficientes para eso; las claves más grandes no están destinadas a aumentar la seguridad, sino a afirmar su estado de macho alfa entre sus compañeros desarrolladores.

Si realmente necesita involucrarse en rituales elaborados de combinación de datos para que, por ejemplo, su jefe tenga la impresión de que "la seguridad está sucediendo" y no se esté aflojando, entonces también puede hacerlo correctamente. No dividir en cambio, dada una secuencia de bytes C (la cadena cifrada), genere una secuencia de bytes aleatorios D de la misma longitud; luego "dividir" C en dos acciones C ₁ = C XOR D , y C ₂ = D . Para ensamblar los recursos compartidos, solo XOROS juntos: sucede que C ₁ XOR C ₂ = C . Ese tipo de división es demostrablemente seguro (un atacante que aprende C ₁ o C ₂ , pero no ambos. aprende exactamente nada , en el sentido de information-theoretic , que es tan bueno como Cualquier criptografía puede obtener). Por supuesto, siempre que no destruyas cosas (DEBES generar una D muy aleatoria y generar una nueva cada vez que tengas una cadena para "dividir").

Debería preocuparse por el almacenamiento seguro de la clave AES, no por dividir los datos. Si la clave está comprometida, realmente no hará ninguna diferencia lo que haya hecho con los datos porque Principio de Kerckhoffs .

Editado para agregar: Más especialmente, no debe almacenar la clave AES en la misma base de datos que contiene los datos cifrados porque un compromiso de la base de datos producirá tanto la clave como los datos. Los compromisos de la base de datos remota, por ejemplo por inyección de SQL, a veces son posibles incluso cuando no se compromete todo el sistema operativo. Guardar la clave en otro lugar es parte de la defensa en profundidad. Lo ideal sería almacenarlo con un módulo de seguridad de hardware (HSM), pero compilarlo en un programa o incluso como un archivo en el sistema de archivos es mucho mejor que el almacenamiento en la base de datos.

Le sugiero que reconsidere su enfoque de este problema. ¿Dónde estás almacenando los datos? Si se encuentra en una base de datos, la mayoría de las bases de datos tienen la capacidad de cifrar los datos de manera bastante segura. ¿Los datos necesitan moverse sobre un canal inseguro? Mira en el HTTPS o FTP seguro. No te metas con Crypto a menos que tú también lo tengas. Es extremadamente fácil equivocarse.