Necesito usar una firma para un JWT que deba crearse o verificarse en 12 servidores diferentes que se ejecutan en un entorno de carga equilibrada. Todos ellos ya tienen el mismo par de claves RSA almacenado en el almacén de certificados de Windows utilizado para servir la aplicación a través de HTTPS.
Esta pregunta ya se ha formulado básicamente aquí: ¿Es el parámetro D del RSA lo suficientemente fuerte como para ser usado como secreto para el cálculo de HMAC? , pero el foco está en la fuerza y / o propósito del cifrado. / p>
Inicialmente, tenía la intención de firmar el JWT con RS256, y escribí el código y todo estuvo bien ... hasta que verifiqué la salida. Obviamente (después del hecho) la firma es bastante larga ... 2048 bits en lugar de 256. El tamaño total de la JWT sin la firma es probablemente solo de 2000 bit o más, por lo que básicamente se duplica El tamaño del token final. El token se utilizará en múltiples solicitudes a servicios posteriores, algunos de ellos con cuerpos de mensajes muy pequeños, por lo que estoy poco reacio a hacer esto.
He analizado varias soluciones DPAPI, .Net Protection y mantengo manualmente un secreto cifrado con la clave pública. Necesito la solución para trabajar en .Net y en .Net Core. Todos ellos presentan problemas relacionados con la creación y la administración de las claves en múltiples entornos, los cuales son totalmente resueltos por la configuración existente si solo uso el valor D como secreto. Entonces ...
¿Por qué NO debo usar el valor D como mi secreto HMAC?