Revisión de seguridad: ¿es segura esta clase de envoltorio mcrypt de PHP?

No, esto no es seguro.

• La verificación HMAC es vulnerable a los ataques de tiempo. Como el autor utiliza una comparación de cadena estándar, la verificación se detiene tan pronto como un carácter del HMAC proporcionado no coincide con el carácter correspondiente del HMAC esperado. De modo que cuanto más largo sea el prefijo común, más tardará la verificación. Al observar cuidadosamente las diferencias de tiempo, un atacante puede reconstruir el HMAC esperado y "forjar" datos arbitrarios. Este es un error conocido .
• El parámetro de longitud de strlen() y substr() se refiere a caracteres en lugar de bytes en algunas configuraciones de PHP, que romperán las funciones críticas de la biblioteca. Por ejemplo, la popular extensión "mbstring" proporciona implementaciones de strlen() y substr() . En este caso, los bytes múltiples se pueden contar como un único carácter de múltiples bytes.
• Se sabe que el cifrado junto con la compresión es problemático en ciertos escenarios (vea el ataque de CRIMEN y INCUMPLIMIENTO contra SSL / TLS). Sin embargo, la función de compresión está desactivada de forma predeterminada.
• La configuración del cifrado es arcana. Por ejemplo, la longitud deseada de la salida PBKDF2 se especifica indirectamente a través de la constante PBKDF2_BLOCK_COUNT , que es el múltiplo mínimo de la salida de la función hash requerida para la longitud objetivo. Esto crea un gran riesgo de errores de los usuarios, especialmente cuando la biblioteca se comercializa como una alternativa fácil a Mcrypt.
• El autor confunde el tamaño de bloque de AES con sus diferentes tamaños de clave. MCRYPT_RIJNDAEL_128 es no AES-128. Los números de las constantes MCRYPT_RIJNDAEL_* se refieren al tamaño de bloque del algoritmo de Rijndael, mientras que los números de las variantes de AES se refieren a diferentes longitudes de clave . AES es Rijndael con un tamaño de bloque de 128 bits y un tamaño de clave de 128 bits, 192 bits o 256 bits. Entonces, para obtener AES en PHP, usas MCRYPT_RIJNDAEL_128 y una cadena de clave con 16, 24 o 32 bytes. La biblioteca utiliza una clave de 32 bytes por defecto, lo que significa que emplea AES-256, no AES-128.
• La derivación de la clave parece bastante extraña: tanto la clave de cifrado como la clave HMAC se basan en la misma salida de la función PBKDF2. La única razón por la que son diferentes es porque las cadenas literales "EncryptionKey" y "AuthenticationKey" se mezclan en la llamada HKDF. Esto no está necesariamente mal. De hecho, el RFC admite específicamente un parámetro de entrada adicional. Pero podría ser más seguro y más robusto generar suficiente material clave para ambas aplicaciones y luego dividirlo.

El problema principal, sin embargo, es que la biblioteca depende en gran medida de implementaciones locales cuando debería usar soluciones estándar. Por ejemplo, la combinación de cifrado y autenticación se debe hacer con AES-GCM. La extensión PHP OpenSSL también proporciona una implementación PBKDF2 completa.

La clase Pixelfck / SymmetricEncryption parece afectar todo lo que buscaría en un sistema de abstracción mcrypt. Está utilizando claves derivadas usando lo que parece ser un algoritmo estándar (PBKDF2), emplea AES128 en modo CFB y usa un hash_hmac de SHA256.

Yo diría que es razonable esperar que esta clase proporcione un cifrado autenticado y no parezca tener ninguno de los errores comunes.

Lo único que veo que debes tener en cuenta es que utiliza MCRYPT_DEV_URANDOM como una fuente aleatoria, lo que podría llevar a un debilitamiento de la seguridad en un uso extremadamente alto en un sistema sin una fuente aleatoria de hardware, pero para la mayoría de las aplicaciones debería trabaja bien.

Lo usaría.