En lo que respecta al rendimiento, el tiempo para calcular un hash MD5 o cualquier otro hash criptográfico depende únicamente del número de bytes. No importa cuáles sean los bytes.
Tenga en cuenta que memset(buffer, ' ', sizeof(buffer)); no crea un "búfer vacío"; no hay nada como un byte vacío en la memoria. Rellena el búfer con caracteres de espacio, que son bytes como 'a' o cualquier otro.
Desde el punto de vista de la seguridad, el tiempo para calcular un hash puede variar muy ligeramente dependiendo de los datos. Esto puede permitir que un atacante que no conozca los datos pero que puede medir con precisión el tiempo que tarda en procesarlo para obtener cierta información sobre los datos. Para un cálculo de hash, es muy poco probable que los ataques de tiempo funcionen en la práctica, porque hay poco en el tiempo que depende de los datos. Los ataques de temporización son en su mayoría exitosos en operaciones con enteros grandes involucrados en criptografía asimétrica, y sobre todo cuando el atacante puede influir en los datos y la velocidad de ejecución. Por ejemplo, si la implementación usa una tabla que no cabe en una sola línea de caché y el atacante puede ejecutar código en el mismo procesador, el atacante podría intentar usar la caché en su propio proceso, de modo que el cálculo de hash continúe obteniéndose. partes de la tabla desde la RAM, lo que permite al atacante observar cuándo se realizan las búsquedas de RAM. La implementación puede contrarrestar eso siendo caché-ajeno .
En la práctica, no me preocuparía por los ataques de tiempo en los cálculos de hash. Comparaciones de hash, sí (al comparar dos hashes MD5, uno de los cuales es secreto, debe comparar los 16 bytes y no detenerse en la primera diferencia). Número de cálculos de hash o comparaciones en un algoritmo que involucra muchos de estos, sí. Pero no para el cálculo de hash en sí.