Respuesta corta: sí tienes razón y puedes hacer esto.
Sin embargo, para estar en el lado seguro, debe asegurarse de no disminuir la seguridad de la función HMAC usándola correctamente y sin poner expectativas erróneas sobre la función utilizada.
Por diseño, las funciones HMAC esperan que un parámetro sea una clave secreta, y el otro es un mensaje que podría ser público (puede encontrar más información here y there ). Esto significa que los argumentos no pueden ser intercambiables libremente, el orden exacto depende del idioma utilizado.
Una clave secreta es una clave:
- Que se compone de caracteres aleatorios elegidos por computadora,
- Cuya longitud mínima es la longitud del hash resultante,
- Lo que nunca es conocido por el usuario remoto, incluso una parte de él,
- El usuario remoto no puede controlarlo o influenciarlo de ninguna manera.
Dependiendo de su necesidad e implementación reales, es posible que no se puedan usar todos los parámetros que proporcionará a la función HMAC como clave secreta:
-
primary_key podría ser un servicio o nombre de dominio para el que necesitará derivar varias claves, en cuyo caso podría ser una cadena pública accesible para el usuario final,
-
keyn (key1, key2, etc.) también puede ser una cadena predecible correspondiente, por ejemplo, al servicio interno para el que se necesita generar la clave.
Aplicado a su pregunta, tenemos las siguientes posibilidades:
-
Ninguno de los parámetros se puede considerar como una clave verdaderamente segura, pero uno de ellos es una contraseña o equivalente : si su
primary_key es una contraseña proporcionada por el usuario (es decir, una cadena aleatoria potencialmente generada por el usuario), puede permanecer seguro utilizando una función de hash dedicada con contraseña . Tal primary_key puede ser vulnerable a ataques de diccionario & co., pero esta amenaza se mitigará con el uso de una función hash adecuada a expensas del rendimiento de la aplicación (tales funciones hash están diseñadas para ser lentas).
-
Ninguno de los parámetros se puede considerar como una clave verdaderamente segura y ni siquiera incluyen una contraseña : un ejemplo de tal situación sería si
primary_key refleja o se deduce del nombre de dominio proporcionado por el usuario y keyn contiene el nombre del servicio o servidor (o se deduce de dicha información) para la cual se generará la clave final. Entonces considera tu sistema como defectuoso, al final de la historia. Su sistema está equivocado y no es seguro.
-
Uno de estos parámetros se puede considerar como una clave segura : preste atención para pasar este parámetro a través del argumento adecuado donde la función HMAC espera la clave secreta. No hacerlo puede afectar la fortaleza criptográfica de la función HMAC. Por ejemplo, digamos que
primary_key es un servicio o nombre de dominio, mientras que keyn es una clave segura, en comparación con su pregunta, es posible que necesite revertir sus argumentos: key1 = HMAC("secret_key_1", primary_key); , consulte la documentación de su idioma en caso de duda. ,
-
Ambos parámetros se pueden considerar como claves seguras : si tiene la seguridad más alta que puede esperar de este esquema, los argumentos se pueden pasar en cualquier orden sin aumentar o disminuir la seguridad (las claves resultantes ser obviamente diferentes pero con las mismas propiedades de seguridad).
Como nota al margen, RFC HMAC también menciona la posibilidad de truncar el hash resultante para reducir la información disponible a un atacante que intentaría deducir primary_key a partir de un hash. Sin embargo, el mismo RFC admite que aunque algunas investigaciones " muestran algunas ventajas analíticas de truncar la salida de funciones MAC basadas en hash ", " los resultados en esta área no son absolutos " . En cuanto a que sus claves iniciales están seguras, tengo la sensación personal de que es posible que tenga más que perder en dicho truncamiento debido a las claves resultantes más cortas. En todos los casos, este RFC recomienda mantener la parte más a la izquierda del hash resultante y mantener al menos la mitad.