Non sono riuscito a trovare la risposta giusta nelle specifiche su come gestire dimensioni della chiave improprie superiori a AES_KEY_SIZE. (Ho trovato che le chiavi con dimensioni ridotte saranno riempite con valori 0x00).
Quindi, ad esempio, se una chiave a 144 bit (anziché la chiave a 128 bit) verrebbe utilizzata per AES-128-ECB, quale dovrebbe essere il comportamento corretto?
Risponderò a sviluppatore e progetterò alcune aggiunte a Crypto-API.
Prima di tutto, Poncho ha ragione che nessuna specifica di AES o modalità di operazione (come la BCE non sicura) indicherà cosa fare in questo caso. Quasi certamente non propongono il n. 2 o il n. 3, se non altro perché ciò avrebbe gravemente alterato qualsiasi prova di sicurezza dell'algoritmo.
L'unica risposta corretta secondo me. AES accetta solo chiavi da 128, 192 o 256 byte. Questa è chiamata pre-condizione. Il mancato rispetto di una pre-condizione dovrebbe comportare un errore. In Java lo aggiornerei rapidamente in RuntimeException poiché fornire meno bit per una chiave simmetrica è sempre un errore di programmazione (non ci si aspetta che un utente inserisca direttamente una chiave, e se è necessario inserire una chiave esadecimale, devi verificarlo prima offrendolo all'API crittografica).
L'unico posto dove questa potrebbe non essere la risposta migliore è molto API di basso livello in cui viene restituito solo un puntatore a una chiave con dimensione nota. Ma gli utenti non dovrebbero mai chiamare o persino avere accesso a quell'API di basso livello.
Restituire un errore (o un'eccezione, per linguaggi di livello superiore) è anche fail-fast , che è una buona pratica di progettazione della sicurezza.
No, è orribile. Non si dovrebbe eseguire una funzione crittografica con meno dati rilevanti per la sicurezza di quelli forniti dall'utente. Decidi per l'utente che è accettabile meno sicurezza, cosa che ovviamente non è il ruolo di un progettista API.
Estendere la chiave con zero è ugualmente orribile. Stai dicendo al tuo utente che stanno usando AES-256 mentre la sicurezza effettiva offerta è inferiore (e forse anche prossima a zero).
Proprio come (3) questo fallirà anche il principio di least surprise .
Le funzioni basate su mcrypt di PHP prendono questa strada e c'è un flusso infinito di domande su SO che tenta di replicare la funzionalità mcrypt in API crittografiche ben gestite.
No. Se l'utente desidera utilizzare un KDF, offri loro un KDF. Esecuzione di un KDF en una modalità di crittografia per AES viola tutti i tipi di principi di progettazione, incluso il principio di least surprise . Un'API AES dovrebbe farlo: offrire un'interfaccia cipher per ottenere riservatezza. Un'API potrebbe renderlo facile per usare un KDF, ma non dovrebbe scegliere un KDF e un insieme di parametri e renderlo predefinito (che in quel momento sembra sicuro e non potrà mai essere modificato in seguito).
Ci sono molti utenti dell'API di CryptoJS che confondono la routine di crittografia che utilizza una password con quella che utilizza una chiave, solo perché hanno lo stesso nome.
Note:
Questa è una domanda API, non una domanda di crittografia. Lo standard AES (FIPS 197) non tiene conto di come vengono gestite le dimensioni delle chiavi non standard. Le implementazioni AES che ho visto tutte rifiutano le dimensioni di chiavi non standard con un errore; tuttavia un'implementazione crittografica di livello superiore (che fa più di "solo AES") potrebbe scegliere di fornire più servizi (a seconda del lavoro per cui è stata progettata).
D'altra parte, la domanda in genere non emerge; Generalmente generiamo una chiave AES con un processo di derivazione chiave, in cui chiediamo espressamente che il processo "ci fornisce 128/192/256 bit di chiave", ed è la chiave che ci fornisce.
Per quanto riguarda le tue alternative, IMHO, troncando silenziosamente il valore chiave è Evil; qual è la cosa giusta dipende da cosa stai effettivamente facendo (e chi sta effettivamente generando la chiave, e perché potrebbe non essere una dimensione standard).
Inoltre, modalità ECB? A meno che tu non sappia esattamente cosa stai facendo (e se devi fare questa domanda, non lo fai), dovresti evitarlo.
Leggi altre domande sui tag aes