migliore modalità operativa per Rijndael-256 in PHP

Per la selezione della modalità: qualsiasi cosa diversa dalla BCE è più sicura. Non preoccuparti troppo (dai un'occhiata al link )

Ma per Rijndael-256 ...

link

Rijndael-256 NON è AES-256. Non usare Rijndael-256 o potresti non riuscire a decifrare (per esempio, con OpenSSL).

link

AES is a variant of Rijndael which has a fixed block size of 128 bits, and a key size of 128, 192, or 256 bits. By contrast, the Rijndael specification per se is specified with block and key sizes that may be any multiple of 32 bits, with a minimum of 128 and a maximum of 256 bits.

E, mcrypt è stato DEPRECATED in PHP 7.1.0 e RIMOSSO in PHP 7.2.0, per favore considera di usare OpenSSL o Sodium

Questo dovrebbe essere un commento, ma è un po 'lungo.

Ho l'impressione che tu stia facendo le domande sbagliate.

Sì, ECB è male, ma solo se il tuo testo cifrato è più di un singolo blocco - e i tuoi dati non lo sono. Se è più lungo, allora qualsiasi modalità di feedback (vale a dire tutto il resto) è un miglioramento.

Stai solo chiedendo informazioni sulle diverse modalità di crittografia o sull'implementazione della crittografia?

Hai solo quattro opzioni per la crittografia in PHP:

• estensione mcrypt
• estensione openssl
• estensione sodio
• Implementazioni basate su PHP

Mentre le attuali versioni di PHP sono abbastanza veloci da gestire la crittografia / decrittografia scritta in PHP, l'utilizzo di un'estensione a un oggetto condiviso comune implica che l'implementazione sottostante abbia un'esposizione molto più ampia - e quindi revisione, test e compatibilità. Nel frattempo libmcrypt è stato descritto come abandonware . Mentre sarebbe bello pensare che gli sviluppatori avrebbero potuto effettivamente produrre qualcosa che è noto per essere privo di bug e resistito alla tentazione di continuare ad aggiungere nuove funzionalità, mi piacerebbe pensare che quegli sviluppatori stiano spingendo fuori le informazioni ogni tanto per dire che stavano ancora tenendo d'occhio le cose e tutto andava bene. Anche se non ho fatto molta attenzione, non ho notato nessuna di queste informazioni. Il rovescio della medaglia è che se ci fossero vulnerabilità note, queste dovrebbero apparire come annunci CVE. Il CVE più recente che riesco a trovare per libmcrypt è del 2003, quindi forse il codice è davvero finito. OTOH l'estensione PHP è ora deprecata.

Non ho guardato l'estensione di sodio in alcun dettaglio.

Come Shawn dice (+1) Rijndael-256 NON è AES-256. Perché deliberatamente scegliere di utilizzare ciò che è effettivamente un algoritmo raro a meno che non si abbiano ragioni molto specifiche, che non hai indicato nella tua domanda. Digressione per un momento .... un motivo valido sarebbe che è necessario mantenere la compatibilità dei dati, ma l'algoritmo da solo non determina questo - si tratta della codifica del testo cifrato, del vettore di inizializzazione e di qualsiasi meccanismo di verifica dell'integrità associato. Quali sono anche le cose che determinano il sovraccarico e influenzano la sicurezza e l'affidabilità della soluzione. Passare a una diversa implementazione dell'algoritmo mantenendo la compatibilità potrebbe significare un sacco di reingegnerizzazione della codifica.

what I am storing is session identifiers

... il che implica che non è necessario mantenere la compatibilità. Se si sta modificando l'implementazione, è sufficiente fornire supporto per 2 diverse implementazioni durante una breve transizione.

Se hai bisogno di molto affidabilità / disponibilità elevata dei dati, allora il punto di partenza è che non hai il testo cifrato nell'implementazione della crittografia.

Considerando che PHP ha fatto molta strada e ha mriptato axe e non volevo andare con un'estensione, sono andato in un modo migliore e sono passato completamente a openSSL con AES-256 normale (blocchi a 128 bit invece dei blocchi a 256 bit in Rijndael-256) e utilizzato modalità CTR a causa delle proprietà di parallelizzazione che lo rendono potenzialmente più veloce sia in en- che in decryption e che, a differenza di per esempio CBC, non ho nemmeno bisogno di non dichiarare l'IR per la IV, qualcosa su cui non voglio fare affidamento.

Onestamente, considero ancora la crittografia autenticata nella mia progettazione (perché qualcosa di simile è già in atto), ma ho apportato alcuni aggiornamenti per giustificarlo. Ma per molte cose è decisamente utile)

Passando a uno schema in stile JWT (per aggiungere più dati che non devono essere crittografati), ho già una firma, non solo sui dati crittografati ma anche sull'intero resto dei dati, che è probabilmente un un po 'più sicuro di JUST che memorizza l'hash in chiaro nel database (che è fondamentalmente una versione remota di MAC-and-Encrypt), non ho più dati da testare prima di derivare la chiave e fare l'intera decrittografia e poi fare cose.