No estoy seguro de si debería preguntar esto aquí o quizás en Security Stackexchange.
En cualquier caso, recientemente estuve trabajando en firmas RSA usando un TPM y me encontré con un problema en el que cambié el esquema de relleno de RSASSA-PKCS1-v1_5 a RSASSA-PSS. Creo que esto no debería marcar la diferencia, pero noté que un ejemplo en TSS.MSR (biblioteca .NET TPM) ya no funciona. Empecé un problema al respecto en https://github.com/microsoft/TSS.MSR/issues/109 .
Pero me gustaría verificar, si alguien puede compartir una opinión, si es necesario hacer o tener en cuenta algo obvio además de cambiar el esquema de relleno.
Creo que no, y esto también está implícito en parámetros como la biblioteca .NET RSA, por ejemplo, https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsasignaturepadding y cómo se puede usar. me gusta
using(var rsaKey = RSA.Create(keySizeInBits: 2048)) { byte[] message = /* Random data. */ var sig = rsaKey.SignData(message, HashAlgorithmName.SHA256, RSASignaturePadding.Pss); }Veo las preguntas en https://security.stackexchange.com/questions/183179/what-is-rsa-oaep-rsa-pss-in-simple-terms , https://crypto.stackexchange.com/questions/77881 /are-rsa-pss-parameters-standardized y en otros lugares cómo ocurre realmente el relleno es más complicado. Pero asumiendo que es un detalle de implementación de la biblioteca y parece ser que las verificaciones de firmas no coinciden o no funcionan, una conclusión es que es posible que deba verificar varios parámetros internos en esta biblioteca TSS.NET, como el relleno. Entonces, por lo tanto, me gustaría asegurarme de que esta conclusión sea lo suficientemente correcta y quizás no haya algo muy obvio. En cuanto a una ilustración: no use SHA-256 ni ponga el tamaño de sal para que sea exactamente nn explícitamente (OK, este es probablemente un detalle de implementación que generalmente no debería importar).
Apéndice:
Escribo esto después de aceptar las excelentes notas de Maarten Bodewes .
Cambiar el hashing de SHA-256 a SHA-1 no eliminó la falla al verificar la firma en el ejemplo vinculado. Aunque, como era de esperar, el "nameSize", o resumen, cambió a 20 bytes. Entonces, si hubo algunos "valores predeterminados persistentes" que no se manejaron correctamente en el ejemplo o en la biblioteca en alguna parte, esto por sí solo (tal vez una solución parcial) no fue la razón por la que no se pudo cambiar al esquema de relleno RSASSA-PSS.
La búsqueda continúa. :)
En realidad, existen algunas opciones de configuración para el relleno, y es necesario establecerlas con anticipación al usar la función.
Por extraño que parezca, estas "opciones" no se describen para la función PSS en el estándar. Sin embargo, se enumeran para el mecanismo de relleno PSS:
Options: Hash hash function (hLen denotes the length in octets of the hash function output) MGF mask generation function sLen intended length in octets of the salt
Sin embargo, esto todavía no configura PSS por completo, ya que el MGF en sí mismo es un algoritmo, y ese algoritmo también tiene parámetros.
Así que probablemente sea mejor mirar la estructura ASN.1 de los parámetros para tener una buena idea:
RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, saltLength [2] INTEGER DEFAULT 20, trailerField [3] TrailerField DEFAULT trailerFieldBC }
Afortunadamente, solo hay una función de generación de máscaras: MGF1. También se especifica un solo campo de tráiler: trailerFieldBC , por lo que se especifica principalmente para cambios futuros.
Como puede ver, hay dos funciones hash allí, una para el mensaje / datos de entrada en sí y otra para la función de generación de máscaras (MGF). Entonces, el hash a su vez es un parámetro de configuración para MGF1. El estándar indica que probablemente sea mejor usar la misma función hash para el hash del mensaje y el hash MGF1. Sin embargo, puede ser que los algoritmos utilicen el valor predeterminado, que es SHA-1, como puede ver en la estructura. AFAIK, Java siempre usa SHA-1 para MGF1 pero .NET usa el mismo hash que el hash del mensaje.
De manera similar, la longitud de sal generalmente se establece en hLen , el tamaño de salida del hash. El valor predeterminado es 20, pero eso se debe a que ese es el tamaño de salida de SHA-1. El valor de cero también es una opción, pero creo que generalmente se deja en 20.
Entonces sí, desafortunadamente debe verificar que se usen los mismos parámetros. Una buena biblioteca debe especificar claramente lo que se usa o al menos tener la opción de configurarlos explícitamente. Sin embargo, si ese es el requisito para una buena biblioteca, entonces existen muchas bibliotecas malas. Además, definitivamente no debe intentar obtener este tipo de información de la firma en sí o adivinar múltiples algoritmos durante la verificación, ya que eso reduciría la seguridad al algoritmo menos seguro posible.
Finalmente, cuando haya encontrado un esquema de PSS seguro y compatible, le recomendaría que especifique claramente en el código qué conjunto de parámetros se utiliza. Esto se puede hacer usando parámetros explícitos (incluso si los valores predeterminados se usan para una biblioteca en particular). También podría indicar los parámetros en un comentario si lo primero no es posible. No estaría de más documentar su esquema por separado y señalarlo en los comentarios.