C'è qualche rischio / rischio per la sicurezza aggiungendo padding aggiuntivo (oltre a quello richiesto) quando si utilizza AES-256 per crittografare stringhe molto brevi?

Il riempimento più lungo non ha svantaggi dal punto di vista della sicurezza e il vantaggio è che perde meno informazioni sulla lunghezza del testo in chiaro. L'unico svantaggio di un maggior numero di padding è la dimensione del testo cifrato più grande, quindi se si considera che l'overhead accettabile per un blocco di dimensioni maggiori è una buona scelta. Ad esempio, in un'applicazione di chat eseguirò il riempimento a multipli di 256 byte o anche a blocchi più grandi.

In linea di principio qualsiasi padding funziona bene, purché sia possibile rimuoverlo senza ambiguità. Raccomando il riempimento deterministico invece del riempimento randomizzato, semplifica i test ed evita preoccupazioni su canali nascosti . Una IV corretta aggiunge già tutta la casualità di cui hai bisogno, e si presume che AES sia sicuro contro gli attacchi di testo in chiaro noti.

Paddings tipici sono 0x80 seguiti da tanti 0x00 come ti piace, o tanti 0x00 come vuoi, seguiti dalla lunghezza del padding o dalla lunghezza del testo in chiaro. Solo un singolo byte non funziona, dal momento che non puoi sapere se un byte fa ancora parte del padding o già parte del messaggio.

Come sempre, ricorda di utilizzare una modalità di crittografia autenticata con un IV appropriato per messaggio. AES-GCM è popolare, ma la scelta convenzionale di AES-CBC combinata con HMAC nell'ordine encrypt-then-MAC va bene, se riesci a implementarlo correttamente.

C'è un vantaggio in termini di sicurezza ed è proprio quello che hai citato.

Se un attaccante sa che le diverse lunghezze del testo cifrato significano qualcosa, non ha bisogno di decodificare il messaggio.

La situazione più estrema (da manuale) è quando si hanno N messaggi e ognuno ha una lunghezza diversa. Se l'aggressore sa cosa significhi ognuno di questi messaggi, può dedurre il tipo di messaggio, ma ancora perdere alcuni dettagli. Questo è ancora un difetto di sicurezza, poiché l'aggressore può dedurre qualcosa dal messaggio, mentre la (buona) crittografia non dovrebbe rivelare nulla che l'attaccante non conoscesse prima di guardare il testo cifrato.

Dal punto di vista del rischio, se non usi la modalità ECB, dovresti essere ok.

Il riempimento aggiuntivo non aumenta necessariamente la sicurezza in questo scenario. Aumenta solo il tempo di decrittazione. Non si eseguono altre operazioni sull'input inserito prima di inviarlo tramite l'algoritmo per la crittografia. Se si utilizza un protocollo personalizzato che esegue operazioni aggiuntive sul testo normale e si utilizza l'algoritmo AES, potrebbe verificarsi un aumento della sicurezza. (Non provarlo, poiché i protocolli personalizzati sono quasi sempre facilmente irrintracciabili fino a meno che non siano approvati da Cryptanalysts)

Dovresti prendere in considerazione anche gli attacchi oracle di Padding. Finché non utilizzi uno schema di riempimento standardizzato e utilizzi byte casuali per il padding, puoi superare questo attacco.