Sobre la eficiencia: el cifrado simétrico (como AES) de nivel de seguridad comparable siempre será más rápido que el asimétrico (como RSA).
Debido a esto (y como RSA necesita un relleno aleatorio para ser seguro, lo que significa que el texto cifrado es un poco más grande que el texto plano), la forma habitual de usar RSA (si tiene que cifrar más del tamaño de la clave) es para generar una clave aleatoria para un algoritmo simétrico, cifre esa clave con RSA, cifre el texto simple con esta clave aleatoria y almacene la clave cifrada junto con el texto simple.
Por lo tanto, su selección es en realidad entre:
- RSA (con clave pública + privada) junto con AES (o algún otro algoritmo, pero seamos sencillos)
- solo AES (con una clave secreta)
La criptografía real aquí no es un punto en el que un atacante obtenga alguna ventaja, tanto AES como RSA (con el tamaño de clave dado) son lo suficientemente seguros para resistir los ataques de fuerza bruta.
Si solo está utilizando el cifrado simétrico, por supuesto, el servidor de cifrado necesita esta clave y, si está comprometido, esta clave se puede usar para descifrar los datos de la base de datos. Realmente no hay una manera de evitar esto.
Si está utilizando un cifrado asimétrico, su servidor de cifrado podría tener solo la clave pública, pero esta es solo una opción viable si este servidor de aplicación web nunca necesita descifrar los datos, es decir, solo para datos de solo escritura. ¿Realmente tienes esos datos? (Puede modificarse después de enviarlo, pero solo sobrescribiéndolo, no leyendo primero, cambiando y escribiendo).
Además, dado que está utilizando una clave pública para el cifrado, no hay nada que impida que un atacante con acceso a la base de datos cambie los datos a otra cosa. Si un atacante de alguna manera obtiene acceso a la base de datos (no debería, por supuesto), no es tan complicado derivar la clave pública de los datos cifrados. Teniendo eso en cuenta, el atacante puede simplemente insertar nuevos registros en la base de datos, o sobrescribir los antiguos, y su proceso de descifrado (con la clave privada) no tiene oportunidad de ver la diferencia. Para evitar esto, haga que el proceso de escritura también firme los datos (con la clave privada de un par de claves diferente), donde el proceso de lectura puede verificar estas firmas.
Puedes tener un segundo servidor para descifrarlo para el primero a pedido, pero esto no será mucho más seguro que el primero que lo haga (solo que puedes cortarlo cuando observes la presencia del atacante) .
Entonces, para estimar completamente su seguridad, es necesario tener primero un modelo de ataque (es decir, contra qué ataques quiere estar seguro), luego puede juzgar qué variante protege mejor.
Quiero estar seguro de que el servidor que enfrenta Internet no sea atacado.
El cifrado de la base de datos por sí solo no abre (ni cierra) ninguna ruta de ataque en el servidor web, de ninguna manera. Solo son diferentes si un atacante encuentra otro agujero de seguridad en su aplicación web y obtiene acceso al servidor web .