Primero, la firma y la verificación son NO 'encriptando' y 'desencriptando' el hash. Ese tropel dañino es casi en parte cierto para RSA pero no realmente, y es totalmente erróneo para DSA y ECDSA. Consulte
¿Intenta comprender RSA y su terminología?
Autenticación de clave pública: ¿qué se firma?
¿Es peligroso cifrar los datos con una clave privada? < br> Si la clave pública no puede ser usado para descifrar algo cifrado por la clave privada, entonces, ¿cómo funcionan las firmas digitales?
Comprensión de las certificaciones digitales
Firma digital y V erification?
Con GPG, ¿puede" descifrar "un archivo que no se haya cifrado?
enlace
Además, el campo del algoritmo de firma en el certificado es irrelevante; ese es el algoritmo para la firma de del certificado por la CA, y no la firma en los datos por la EE (aquí el servidor) usando la clave certificada.
Dicho esto, lo que está firmado son los dos valores aleatorios, más la forma codificada de server-params.
Aquí hay un ejemplo. Capturé un protocolo de enlace (de prueba) en Wireshark y aquí exporto el mensaje ServerKeyExchange a temp3.raw
:
También exporté las llamadas de cliente y servidor a temp1.raw
y temp2.raw
respectivamente, y el subjectPublicKeyInfo
del certificado a tempk.raw
y lo convertí a la forma PEM (que OpenSSL prefiere) con openssl pkey -pubin -inform der <tempk.raw >tempk.pem
. Ahora:
$ xxd temp1.raw
0000000: ead0 1445 aec2 291d e316 8f77 b75c e0ec ...E..)....w.\..
0000010: 696c ced0 9d45 65b3 78bd d6f8 5e11 287e il...Ee.x...^.(~
$ xxd temp2.raw
0000000: 5834 4f06 be02 498d cba5 16b0 80bd d5f3 X4O...I.........
0000010: 4a0c 1476 d085 8c57 6fbf 5485 47cd 3937 J..v...Wo.T.G.97
$ xxd temp3.raw
0000000: 0c00 0091 0300 1741 04da 0889 2ed6 bdd0 .......A........
0000010: d140 30e8 417a 7d15 9d46 55b5 6eed 4fde [email protected]}..FU.n.O.
0000020: 814c a7aa fd1d 6617 2835 75c4 12d4 a2a4 .L....f.(5u.....
0000030: 213e 6141 112c fb8d 620b 21f9 e27f ea54 !>aA.,..b.!....T
0000040: 53ec 9ec1 bbbc b3df 2f06 0300 4830 4602 S......./...H0F.
0000050: 2100 fd47 429f 478b 3bd4 c8d4 ce4a 9e4c !..GB.G.;....J.L
0000060: f6e0 c957 bf83 017d 0812 bb4a 8fda de06 ...W...}...J....
0000070: ddc0 0221 00e3 05b1 3046 3c32 a387 012f ...!....0F<2.../
0000080: d149 e810 b423 b45c cce1 e4e9 62ce bd6a .I...#.\....b..j
0000090: a4a0 b6d2 a3 .....
Este ServerKeyExchange
consiste en el encabezado del mensaje de intercambio (4 bytes), el nombre de curva y la clave de publicación codificados que suman 3 + 1 + 65 = 69 bytes, firma de 2 bytes e identificadores de hash (solo TLSv1.2, para una vista anterior los RFC) aquí 06 03
significa SHA512 ECDSA, 2 bytes de longitud y 72 bytes de firma real. Construyo la entrada y separo la firma, y uso la línea de comandos de OpenSSL para (hash &) verificar:
$ (cat temp[12].raw;dd if=temp3.raw bs=1 skip=4 count=69 status=none) >temp.dat
$ dd if=temp3.raw bs=1 skip=77 count=72 status=none >temp.sig
$ openssl sha512 <temp.dat -verify tempk.pem -signature temp.sig
Verified OK