2012-05-29 6 views
5

RFC 4880 describe la versión 4 paquete de firma, etiqueta 2, comoOpenPGP paquete de firma de hash de datos

- One-octet signature type. 
- One-octet public-key algorithm. 
- One-octet hash algorithm. 
- Two-octet scalar octet count for following hashed subpacket data. 
Note that this is the length in octets of all of the hashed 
subpackets; a pointer incremented by this number will skip over 
the hashed subpackets. 
- Hashed subpacket data set (zero or more subpackets). 
- Two-octet scalar octet count for the following unhashed subpacket 
data. Note that this is the length in octets of all of the 
unhashed subpackets; a pointer incremented by this number will 
skip over the unhashed subpackets. 
- Unhashed subpacket data set (zero or more subpackets). 
- Two-octet field holding the left 16 bits of the signed hash 
value. 
- One or more multiprecision integers comprising the signature. 

y supongo que la segunda a la última línea significa simplemente tomar la cadena del subpaquete hash y hash con el algoritmo hash y toma sus primeros 2 bytes. sin embargo, no importa lo que haga, no puedo entenderlo.

que generaron esta falsa llave de un largo tiempo atrás

-----BEGIN PGP PUBLIC KEY BLOCK----- 
Version: BCPG v1.39 

mQGiBE5B0h8RBAD533Z5bK1IpBx02QyQL0QoJE4uFRIMGDiwXuwmZzVl+R7Vlurd 
GRLsCCbE6vOOh7XQVZGzLEBy9WNzZ9m+EbCfSVAYkjS6FhLws6hG6irrnS+b3JBf 
gFJ8vNGF9Z7bhx+7y7NBk0IMyWkGnUkcnav73t5FQUI2faEBN4c/yAGJZwCgjcB7 
3akWk9XVWvTCsiMXxpyvkukEALXsvB6cOoFEtQq9cQHjP63fBlvD94dhhMiM0cH6 
hW9JotxdK+cxFGG9ZIWgoN2PWbMJka/H4W5EL6tS+YiNAR7I1Ozkt6X16GjnQUzZ 
MlSpleK+KiKVN2anRaPEoOIinHrE3ZXd6QlJ/4+OJn4IVWmSEaJpFf4QNgvEu4rh 
xinyBAD2RNzREOA+wpnFZ4lDt9NZXmXdxQME/l0J9XcvWhpGsxA/MATQKImy7N49 
7GT/M38F+TrpBobag1O3buE99fOLyws4Tbc+sZMdHxoiGZDAIRNQS2rv475E6ktj 
7vd5CYvOkA6+8sX1+hPcNlkHtHB1OFkJRsYp6k0zkyC9adjBM7QTYWJjIDxtYWtj 
bUBhYWEuY29tPohGBBMRAgAGBQJOQdIfAAoJEDBSJUXPd92GRSQAoItbtbToOg7a 
/hcg2sA/aBEQNwuxAKCGR69vmSoCWoBP5waPk0UsjM3BSbjMBE5B0h8QAgCUlP7A 
lfO4XuKGVCs4NvyBpd0KA0m0wjndOHRNSIz44x24vLfTO0GrueWjPMqRRLHO8zLJ 
S/BXO/BHo6ypjN87Af0VPV1hcq20MEW2iujh3hBwthNwBWhtKdPXOndJGZaB7lsh 
LJuWv9z6WyDNXj/SBEiV1gnPm0ELeg8Syhy5pCjMAf9QHehP2eCFqfEwTAnaOlA6 
CU+rYHKPZaI9NUwCA7qD2d93/l08/+ZtFvejZW1RWrJ8qfLDRtlPgRzigoF/CXbR 
iEYEGBECAAYFAk5B0h8ACgkQMFIlRc933YZRrACfUnWTjHHN+QsEEoJrwRvFmvzj 
bR4An24pTpeeN+I6R59O/sdmYsAhjULX 
=sStS 
-----END PGP PUBLIC KEY BLOCK----- 

lo que pienso im supone que debe hacer:

sha1("\x05\x02\x4e\x41\xd2\x1f") = "52f07613cfd61c80d2343566a8f3f487a0975b80" 

\x05 - length of subpacket 
\x02 - subpacket type 
\x4e\x41\d2\x1f - creation time 

De pgpdump.net, veo que la izquierda 2 bytes del hash (SHA 1) el valor es 45 24 para el primer paquete de firma y 51 ac para el segundo. recibo 52 f0 para ambos. obviamente, no estoy incluyendo alguna información, pero ¿qué es? los subpaquetes hash son idénticos, y todos los datos antes de los datos hash son iguales, excepto que son diferentes tipos de paquetes de firma (0x13/0x18). No he podido obtener ninguno de los valores hash correctos incluso cuando agrego/tomo caracteres del paquete de datos. la clave que estoy generando es exactamente la misma que la clave que se muestra aquí excepto por los valores hash.

lo son los datos que yo debería ser de hash ??

edición: si se encuentra presente un poco más adelante:

The concatenation of the data being signed and the signature data 
from the version number through the hashed subpacket data (inclusive) 
is hashed. The resulting hash value is what is signed. The left 16 
bits of the hash are included in the Signature packet to provide a 
quick test to reject some invalid signatures. 

pero lo que se está firmando los datos? todos los paquetes antes de la firma? solo el paquete antes del paquete de firma actual?

el ejemplo clave arriba está formado por packet 6 + packet 13 + packet 2 + packet 14 + packet 2. he intentado todo tipo de combinaciones de packet 6, packet 13 y packet 2 (de número de versión de hash de datos incluido), pero todavía no puede encontrar la cadena que los hashes a los valores correctos

Respuesta

2

Cuando se genera un paquete de firma, que es siempre una firma de algo por alguien. Es decir, hay una cierta cantidad de datos que se firman, y una clave pública, y el punto de una firma es que es algo que solo se supone que puede ser realizado por alguien que tenga los datos exactos y la clave privada correspondiente.

Por lo tanto, "los datos que se firman" serán los que sean. Ver la sección 5.2.1 de RFC4880 para algunos ejemplos. En el presente caso, presumiblemente está interesado en los paquetes de firma dentro de su bloque de clave pública.

La primera es una "Certificación positiva de un ID de usuario y paquete de clave pública (0x13)". Esto se describe en la sección 5.2.4 de RFC4880.

La segunda es una "firma de enlace de subclave", donde la clave principal (la DSA uno) garantiza que la subclave (solo ElGamal encrypt) pertenece a ella. La forma en que esto funciona también se describe en la sección 5.2.4 de RFC4880.

Aquí está el texto relevante de 5.2.4:

Cuando una firma se hace sobre una tecla, los datos de hash comienza con la octeto 0x99, seguido de una longitud de dos octetos de la clave, y luego cuerpo del paquete de claves. (Tenga en cuenta que este es un encabezado de paquete antiguo para un paquete clave con dos octetos de longitud.) Una firma de enlace de subclave (tipo 0x18) o una firma de enlace de clave principal (tipo 0x19) y luego hash la subclave utilizando el mismo formato como la clave principal (también utilizando 0x99 como el primer octeto ). Las firmas de revocación de claves (tipos 0x20 y 0x28) hash solo la clave está revocada.

y luego

Una firma de certificación (tipo 0x10 a través de 0x13) codifica la ID de usuario estando unido a la llave en el contexto de hash después de los datos anteriores. Una certificación V3 hashes el contenido de la identificación de usuario o el paquete de paquete de atributo , sin ningún encabezado. Una certificación V4 codifica la constante 0xB4 para certificaciones de ID de usuario o la 0xD1 constante para el usuario Certificaciones de atributo, seguido de un número de cuatro octetos que proporciona la longitud de los datos de ID de usuario o atributo de usuario y luego la ID de usuario o usuario Datos de atributos.

Cuestiones relacionadas