el mejor modo de operación para Rijndael-256 en PHP

Para la selección de modo: cualquier otra cosa que no sea ECB es más segura. No se preocupe demasiado (consulte enlace )

Pero para Rijndael-256 ...

enlace

Rijndael-256 NO ES AES-256. No utilice Rijndael-256 o puede que no pueda descifrar (por ejemplo, mediante OpenSSL).

enlace

  

AES es una variante de Rijndael que tiene un tamaño de bloque fijo de 128 bits,   y un tamaño de clave de 128, 192 o 256 bits. Por el contrario, el Rijndael   La especificación per se se especifica con tamaños de bloque y clave que pueden ser   cualquier múltiplo de 32 bits, con un mínimo de 128 y un máximo de 256   bits.

Y, mcrypt fue DEPRECATED en PHP 7.1.0, y QUITADO en PHP 7.2.0, considere usar OpenSSL o Sodium

Esto debería ser un comentario, pero es un poco largo.

Tengo la impresión de que estás haciendo las preguntas incorrectas.

Sí, el BCE es malo, pero solo si su texto cifrado es más que un solo bloque, y sus datos no lo son. Si es más largo, entonces cualquiera de los modos de retroalimentación (es decir, todo lo demás) es una mejora.

¿Está preguntando acerca de los diferentes modos de cifrado, o sobre la implementación del cifrado?

Solo tiene cuatro opciones de cifrado en PHP:

• extensión mcrypt
• extensión openssl
• extensión de sodio
• Implementaciones basadas en PHP

Si bien las versiones actuales de PHP son lo suficientemente rápidas para manejar el cifrado / descifrado escrito en PHP, el uso de una extensión para un objeto compartido común implica que la implementación subyacente tiene una exposición mucho más amplia, y por lo tanto, revisiones, pruebas y compatibilidad. Mientras tanto, se ha descrito a libmcrypt como abandonware . Si bien sería bueno pensar que los desarrolladores podrían realmente haber producido algo que se sabe que está libre de errores y resistido a la tentación de seguir agregando nuevas funciones, me gustaría pensar que esos desarrolladores estarían publicando información de vez en cuando decir que todavía estaban vigilando las cosas y que todo estaba bien. Aunque no he mirado mucho, no he notado tal información. La otra cara es que si existieran vulnerabilidades conocidas, estas deberían aparecer como anuncios de CVE. El CVE más reciente que puedo encontrar para libmcrypt es de 2003, así que tal vez el código realmente esté terminado. OTOH la extensión de PHP ahora está en desuso.

No he mirado la extensión de sodio en ningún detalle.

Como dice Shawn (+1) Rijndael-256 NO es AES-256. ¿Por qué elegir deliberadamente usar lo que es efectivamente un algoritmo poco común a menos que tenga razones muy específicas, que no haya indicado en su pregunta? Desentrañando por un momento ... una razón válida sería que necesita mantener la compatibilidad de los datos, pero el algoritmo por sí solo no determina esto: se trata de la codificación del texto cifrado, el vector de inicialización y cualquier mecanismo de verificación de integridad asociado. Cuáles son también las cosas que determinan la sobrecarga y afectan la seguridad y la fiabilidad de la solución. Cambiar a una implementación diferente del algoritmo mientras se mantiene la compatibilidad podría significar mucha reingeniería de la codificación.

  

lo que estoy almacenando son identificadores de sesión

... lo que implica que no es necesario mantener la compatibilidad. Si está cambiando la implementación, simplemente debe proporcionar soporte para 2 implementaciones diferentes durante una transición corta.

Si necesita muy alta confiabilidad / disponibilidad de los datos, entonces el lugar para abordar esto es después de que el texto cifrado no esté en la implementación del cifrado.

Teniendo en cuenta que PHP ha recorrido un largo camino y ha eliminado mcrypt y no quería ir con una extensión, fui mejor y cambié completamente a openSSL con normal AES-256 (bloques de 128 bits en lugar de los bloques de 256 bits en Rijndael-256) y usó modo CTR debido a las propiedades de paralelización que lo hacen potencialmente más rápido tanto en la encriptación como en la desencriptación, y eso, a diferencia de p.ej CBC, tampoco necesito una capacidad de redención para el IV, algo en lo que realmente no quiero confiar.

Sinceramente, todavía considero que el criptográfico autentificado es bastante inútil en mi Diseño (porque ya hay algo similar), pero sí realicé algunas mejoras más para justificarlo. Pero para muchas cosas es definitivamente útil)

Al cambiar a un esquema de estilo JWT (para agregar más datos que no necesitan estar cifrados), ya tengo una Firma, no solo sobre los datos cifrados sino también sobre el resto de los datos, lo que probablemente sea un Un poco más seguro que JUSTAMENTE almacenando el hash de texto sin formato en la base de datos (que es básicamente una versión remota de MAC-and-Encrypt), no tengo más datos para realizar una prueba previa antes de derivar la clave y hacer todo el descifrado y luego hacer cosas.