Revisione sicurezza: questa classe wrapper mcrypt di PHP è sicura?

No, non è sicuro.

• Il controllo HMAC è vulnerabile agli attacchi temporali. Poiché l'autore utilizza un confronto di stringhe standard, la verifica si interrompe non appena un carattere dall'HMAC fornito non corrisponde al carattere corrispondente dall'HMAC previsto. Quindi più lungo è il prefisso comune, più lungo è il controllo. Osservando attentamente tali differenze temporali, un aggressore potrebbe essere in grado di ricostruire l'HMAC previsto e "falsificare" dati arbitrari. Questo è un errore noto .
• Il parametro length di strlen() e substr() fa riferimento a caratteri piuttosto che a byte in alcune configurazioni PHP, che interrompono le funzionalità critiche della libreria. Ad esempio, la popolare estensione "mbstring" fornisce implementazioni di encoding-aware di strlen() e substr() . In questo caso, più byte possono essere contati come un singolo carattere multi-byte.
• È noto che la crittografia associata alla compressione è problematica in alcuni scenari (vedere l'attacco CRIME e BREACH contro SSL / TLS). La funzione di compressione è disattivata di default, però.
• La configurazione della cifra è arcana. Ad esempio, la lunghezza desiderata dell'uscita PBKDF2 viene specificata indirettamente tramite la costante PBKDF2_BLOCK_COUNT , che rappresenta il multiplo minimo dell'output della funzione hash richiesto per la lunghezza di destinazione. Ciò crea un enorme rischio di errori da parte degli utenti, specialmente quando la libreria è commercializzata come una facile alternativa a Mcrypt.
• L'autore confonde la dimensione del blocco di AES con le sue varie dimensioni di chiave. MCRYPT_RIJNDAEL_128 è non AES-128. I numeri delle costanti MCRYPT_RIJNDAEL_* si riferiscono alla dimensione del blocco dell'algoritmo Rijndael, mentre i numeri delle varianti AES si riferiscono a diverse lunghezze . AES è Rijndael con una dimensione del blocco di 128 bit e una dimensione della chiave di 128 bit, 192 bit o 256 bit. Quindi per ottenere AES in PHP, si usa MCRYPT_RIJNDAEL_128 e una stringa chiave con 16, 24 o 32 byte. La libreria utilizza una chiave a 32 byte per impostazione predefinita, il che significa che utilizza AES-256, non AES-128.
• La derivazione della chiave sembra piuttosto strana: sia la chiave di crittografia che la chiave HMAC si basano sullo stesso output della funzione PBKDF2. L'unico motivo per cui sono diversi è perché le stringhe letterali "EncryptionKey" e "AuthenticationKey" sono mescolate nella chiamata HKDF. Questo non è necessariamente sbagliato. In effetti, RFC supporta in modo specifico un parametro di input aggiuntivo. Ma potrebbe essere più sicuro e più robusto generare abbastanza materiale chiave per entrambe le applicazioni e quindi dividerlo.

Il problema principale, tuttavia, è che la libreria si basa pesantemente su implementazioni interne quando dovrebbe utilizzare soluzioni standard. Ad esempio, combinando la crittografia e l'autenticazione dovrebbe essere fatto con AES-GCM. L'estensione PHP OpenSSL fornisce anche un'implementazione PBKDF2 completa.

La classe Pixelfck / SymmetricEncryption sembra colpire tutto ciò che cerco in un sistema di astrazione mcrypt. Usa le chiavi derivate usando quello che sembra essere un algoritmo standard (PBKDF2), impiega AES128 in modalità CFB e usa un hash_hmac di SHA256.

Direi che è ragionevole aspettarsi che questa classe fornisca la crittografia autenticata e non sembra che abbia nessuno degli errori più comuni.

L'unica cosa che vedo di cui devi essere a conoscenza è l'utilizzo di MCRYPT_DEV_URANDOM come una fonte casuale, che potrebbe portare a un indebolimento della sicurezza in caso di utilizzo estremamente elevato su un sistema senza una sorgente hardware casuale, ma per la maggior parte delle applicazioni dovrebbe funziona bene

Lo userei.