Per quanto riguarda le prestazioni, il tempo per calcolare un hash MD5 o qualsiasi altro hash crittografico dipende esclusivamente dal numero di byte. Non importa cosa siano i byte.
Si noti che memset(buffer, ' ', sizeof(buffer)); non crea un "buffer vuoto" - non c'è nulla come un byte vuoto in memoria. Riempie il buffer con caratteri di spazio, che sono byte come 'a' o qualsiasi altro.
Per quanto riguarda la sicurezza, il tempo di calcolare un hash può variare molto leggermente a seconda dei dati. Ciò potrebbe consentire a un utente malintenzionato che non conosce i dati ma può misurare con precisione il tempo necessario per cancellarlo per ottenere alcune informazioni sui dati. Per un calcolo hash, è molto improbabile che gli attacchi temporali funzionino nella pratica, perché i tempi dipendono poco dai dati. Gli attacchi a tempo sono per lo più efficaci su operazioni su interi di grandi dimensioni coinvolti nella crittografia asimmetrica, e soprattutto quando l'attaccante può influenzare i dati e la velocità di esecuzione. Ad esempio, se l'implementazione utilizza una tabella che non rientra in una singola riga della cache e l'utente malintenzionato può eseguire codice sullo stesso processore, l'utente malintenzionato potrebbe provare a utilizzare la cache nel proprio processo, in modo che il calcolo dell'hash continui a recuperare parti della tabella dalla RAM, consentendo all'aggressore di osservare quando avvengono le ricerche RAM. L'implementazione può contrastare questo essendo cache-ignaro .
In pratica, non mi preoccuperei degli attacchi temporali ai calcoli hash. Confronto hash, sì (quando si confrontano due hash MD5, uno dei quali è segreto, è necessario confrontare tutti i 16 byte e non fermarsi alla prima differenza). Numero di calcoli hash o confronti in un algoritmo che coinvolge molti di questi, sì. Ma non per lo stesso calcolo dell'hash.