Supongo aquí que key es algo estático a nivel del sistema, y no algo que un usuario individual elija. Si es así, es muy extraño que se lea como UTF-8 en lugar de como Base64 porque UTF-8 será un mecanismo de almacenamiento ineficiente para la clave, ya que no utilizará el espacio completo. Daría esto a la ingenuidad del desarrollador en lugar de hacer cualquier cosa fuera de razón.
Este método tendría más sentido si fuera para una clave elegida por el usuario, ya que pueden haber ingresado caracteres Unicode como clave y, por lo tanto, si se almacena y se lee como UTF-8, se puede colocar en una clave. Función de estiramiento tal como PBKDF2. En este caso, el objetivo no es un almacenamiento eficiente, sino simplemente asegurarse de que una clave elegida por el usuario tenga suficiente entropía para ser útil.
¿no significa que esta clave es más predecible de lo que debería ser?
Cuando la tecla ingresa a la función HMAC, se incluye junto con el mensaje. El hecho de que sea de una cadena UTF-8 no debería hacer que los HMAC resultantes sean más predecibles ni debería hacer que la clave de forzoso sea más fácil. Siempre que la cadena original tenga suficiente entropía para comenzar, no importará a qué formato se haya convertido para el almacenamiento.
¿Puede seguir siendo lo suficientemente seguro siempre y cuando la generación adecuada de este
clave, y cómo se debe generar en este caso?
De esta respuesta , se recomendaría un valor aleatorio de 128 bits generado a través de un generador de números pseudoaleables criptográficamente seguro por la llave El CSPRNG generaría una secuencia de bytes, por lo que podría ser Base64'd y luego almacenarse como UTF-8, aunque el espacio de teclas nunca se complete completamente. Sería mejor si el paso UTF-8 pudiera eliminarse por completo, porque agrega una complejidad innecesaria.