¿Por qué el "bloque de clave pública" es diferente aunque la huella digital es la misma para las claves de gpg?

4

Soy nuevo en pgp & tratando de entender cómo funciona.

La clave de firma de

nginx se encuentra aquí: enlace

Su huella digital es: 573B FD6B 3D8F BC64 1079 A6AB ABF5 BD82 7BD9 BF62

Si busco la clave de nginx en pgp.mit.edu , obtengo una clave ascii de aspecto diferente cuya huella digital es la misma que la anterior.

¿Por qué las partes del "bloque de clave pública" son diferentes aunque las claves son las mismas?

    
pregunta user 10.02.2017 - 10:48
fuente

3 respuestas

2

La huella digital de una clave se calcula sobre las partes de la misma que son relevantes para garantizar que tenga la clave pública correcta.

Pero una clave pública PGP puede contener más información que esa; por ejemplo, puede contener una imagen de retrato, puede contener firmas de personas que confían en su clave, sus direcciones de correo electrónico, etc. El orden de estos elementos puede cambiar sin cambiar la huella dactilar, y si una clave contiene o no una imagen no hace nada para cambiar la huella dactilar, porque el retrato o el orden en que se almacenan estos elementos no es relevante para autenticar la clave. / p>

Es probable que el servidor de claves cambie algunas de las partes no relevantes de la clave; para obtener otro bloque clave, pero la misma huella digital.

Imagina que alguien se metió con la llave de Bob en el servidor de llaves para cambiar la imagen de retrato que contiene. La huella digital se mantendría igual porque, incluso con el retrato incorrecto, si Alice utilizara la clave para cifrar un mensaje a Bob, solo podría descifrarla con la clave privada de Bob.

Sin embargo, si Malory dejara solo el retrato de Bob pero reemplazara el módulo y el exponente de la clave pública con la suya, esto cambiaría la huella dactilar, y con razón: ya no sería la clave de Bob, y cifrar algo con ella daría Acceso a Malory a través de la clave privada de Malory.

Nosotros podríamos crear la huella digital sobre todos los elementos de una clave pública, por ejemplo. incluyendo todas las firmas e información personal adicional sobre el propietario de la clave, pero si funcionara así, entonces cada vez que actualice alguna información trivial en su clave, o alguien le agregue otra firma, su huella digital de clave cambiará, y usted Debes explicar a todos que no, tu clave no fue pirateada, solo colocaste una nueva imagen de retrato donde tu sonrisa era más radiante.

    
respondido por el Pascal 10.02.2017 - 11:30
fuente
2

Un bloque de claves GPG no es un solo valor de clave, sino que consta de varios paquetes de diferentes tipos, siguiendo el formato de mensaje OpenPGP .

En su caso, ambos bloques contienen el mismo paquete clave pública y ID de usuario , pero la segunda clave enumera algunas herramientas adicionales signature packets .

Puedes usar gpg(1) con --list-packets para enumerarlos de la siguiente manera:

$ gpg --list-packets nginx_signing.key 

# off=0 ctb=99 tag=6 hlen=3 plen=269
:public key packet:
    version 4, algo 1, created 1313747554, expires 0
    pkey[0]: [2048 bits]
    pkey[1]: [17 bits]
    keyid: ABF5BD827BD9BF62
# off=272 ctb=b4 tag=13 hlen=2 plen=41
:user ID packet: "nginx signing key "
# off=315 ctb=89 tag=2 hlen=3 plen=318
:signature packet: algo 1, keyid ABF5BD827BD9BF62
    version 4, created 1466086904, md5len 0, sigclass 0x13
    digest algo 2, begin of digest 5a 1a
    hashed subpkt 27 len 1 (key flags: 03)
    hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
    hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
    hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
    hashed subpkt 30 len 1 (features: 01)
    hashed subpkt 23 len 1 (keyserver preferences: 80)
    hashed subpkt 2 len 4 (sig created 2016-06-16)
    hashed subpkt 9 len 4 (key expires after 12y303d4h27m)
    subpkt 16 len 8 (issuer key ID ABF5BD827BD9BF62)
    data: [2047 bits]
# off=636 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid A64FD5B17ADB39A8
    version 4, created 1313752997, md5len 0, sigclass 0x10
    digest algo 2, begin of digest ef da
    hashed subpkt 2 len 4 (sig created 2011-08-19)
    subpkt 16 len 8 (issuer key ID A64FD5B17ADB39A8)
    data: [2047 bits]
# off=923 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid ECF0E90B2C172083
    version 4, created 1313758162, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 51 be
    hashed subpkt 2 len 4 (sig created 2011-08-19)
    subpkt 16 len 8 (issuer key ID ECF0E90B2C172083)
    data: [160 bits]
    data: [158 bits]
# off=995 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid A9376139A524C53E
    version 4, created 1313759073, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 73 56
    hashed subpkt 2 len 4 (sig created 2011-08-19)
    subpkt 16 len 8 (issuer key ID A9376139A524C53E)
    data: [159 bits]
    data: [156 bits]

Ahora nuevamente con la clave de pgp.mit.edu :

$ gpg --list-packets nginx_signing2.key 

# off=0 ctb=99 tag=6 hlen=3 plen=269
:public key packet:
    version 4, algo 1, created 1313747554, expires 0
    pkey[0]: [2048 bits]
    pkey[1]: [17 bits]
    keyid: ABF5BD827BD9BF62
# off=272 ctb=b4 tag=13 hlen=2 plen=41
:user ID packet: "nginx signing key "
# off=315 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid ECF0E90B2C172083
    version 4, created 1313758162, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 51 be
    hashed subpkt 2 len 4 (sig created 2011-08-19)
    subpkt 16 len 8 (issuer key ID ECF0E90B2C172083)
    data: [160 bits]
    data: [158 bits]
# off=387 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid A9376139A524C53E
    version 4, created 1313759073, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 73 56
    hashed subpkt 2 len 4 (sig created 2011-08-19)
    subpkt 16 len 8 (issuer key ID A9376139A524C53E)
    data: [159 bits]
    data: [156 bits]
# off=459 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid E3F93C24A0AF822A
    version 4, created 1393414117, md5len 0, sigclass 0x10
    digest algo 10, begin of digest b2 d5
    hashed subpkt 2 len 4 (sig created 2014-02-26)
    subpkt 16 len 8 (issuer key ID E3F93C24A0AF822A)
    data: [159 bits]
    data: [160 bits]
# off=531 ctb=88 tag=2 hlen=2 plen=94
:signature packet: algo 17, keyid 6B76D872E5287DB2
    version 4, created 1453519845, md5len 0, sigclass 0x10
    digest algo 8, begin of digest ff c0
    hashed subpkt 2 len 4 (sig created 2016-01-23)
    subpkt 16 len 8 (issuer key ID 6B76D872E5287DB2)
    data: [254 bits]
    data: [255 bits]
# off=627 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid A64FD5B17ADB39A8
    version 4, created 1313752997, md5len 0, sigclass 0x10
    digest algo 2, begin of digest ef da
    hashed subpkt 2 len 4 (sig created 2011-08-19)
    subpkt 16 len 8 (issuer key ID A64FD5B17ADB39A8)
    data: [2047 bits]
# off=914 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid 676B7CC30978D14B
    version 4, created 1387022054, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 58 70
    hashed subpkt 2 len 4 (sig created 2013-12-14)
    subpkt 16 len 8 (issuer key ID 676B7CC30978D14B)
    data: [2046 bits]
# off=1201 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid 63563037DB85C154
    version 4, created 1477007959, md5len 0, sigclass 0x10
    digest algo 10, begin of digest cf 83
    hashed subpkt 2 len 4 (sig created 2016-10-20)
    subpkt 16 len 8 (issuer key ID 63563037DB85C154)
    data: [2047 bits]
# off=1488 ctb=89 tag=2 hlen=3 plen=318
:signature packet: algo 1, keyid ABF5BD827BD9BF62
    version 4, created 1466086904, md5len 0, sigclass 0x13
    digest algo 2, begin of digest 5a 1a
    hashed subpkt 27 len 1 (key flags: 03)
    hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
    hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
    hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
    hashed subpkt 30 len 1 (features: 01)
    hashed subpkt 23 len 1 (keyserver preferences: 80)
    hashed subpkt 2 len 4 (sig created 2016-06-16)
    hashed subpkt 9 len 4 (key expires after 12y303d4h27m)
    subpkt 16 len 8 (issuer key ID ABF5BD827BD9BF62)
    data: [2047 bits]
# off=1809 ctb=89 tag=2 hlen=3 plen=318
:signature packet: algo 1, keyid ABF5BD827BD9BF62
    version 4, created 1313747554, md5len 0, sigclass 0x13
    digest algo 2, begin of digest 9b e3
    hashed subpkt 2 len 4 (sig created 2011-08-19)
    hashed subpkt 27 len 1 (key flags: 03)
    hashed subpkt 9 len 4 (key expires after 5y0d0h0m)
    hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
    hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
    hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
    hashed subpkt 30 len 1 (features: 01)
    hashed subpkt 23 len 1 (keyserver preferences: 80)
    subpkt 16 len 8 (issuer key ID ABF5BD827BD9BF62)
    data: [2047 bits]
# off=2130 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid EB17F674C79A40A2
    version 4, created 1453812587, md5len 0, sigclass 0x10
    digest algo 2, begin of digest d6 ea
    hashed subpkt 2 len 4 (sig created 2016-01-26)
    subpkt 16 len 8 (issuer key ID EB17F674C79A40A2)
    data: [4096 bits]
# off=2673 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 6D688C7C498BF352
    version 4, created 1474279425, md5len 0, sigclass 0x10
    digest algo 8, begin of digest b5 32
    hashed subpkt 2 len 4 (sig created 2016-09-19)
    subpkt 16 len 8 (issuer key ID 6D688C7C498BF352)
    data: [4096 bits]
# off=3216 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 6D688C7C498BF352
    version 4, created 1474423494, md5len 0, sigclass 0x10
    digest algo 8, begin of digest f1 d9
    hashed subpkt 2 len 4 (sig created 2016-09-21)
    subpkt 16 len 8 (issuer key ID 6D688C7C498BF352)
    data: [4096 bits]
# off=3759 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 1465F6CF06C1F0CD
    version 4, created 1471971424, md5len 0, sigclass 0x10
    digest algo 10, begin of digest d7 b0
    hashed subpkt 2 len 4 (sig created 2016-08-23)
    subpkt 16 len 8 (issuer key ID 1465F6CF06C1F0CD)
    data: [4095 bits]
# off=4302 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid A22AE4EB4329C545
    version 4, created 1381544106, md5len 0, sigclass 0x12
    digest algo 2, begin of digest 0a 50
    hashed subpkt 2 len 4 (sig created 2013-10-12)
    subpkt 16 len 8 (issuer key ID A22AE4EB4329C545)
    data: [4096 bits]

Como puede ver, los paquetes de clave pública de ambos bloques tienen la misma ID de clave ( ABF5BD827BD9BF62 ). La diferencia de tamaño se debe a los diferentes paquetes de firma, mientras que la clave pública en sí misma es idéntica.

    
respondido por el Arminius 10.02.2017 - 11:48
fuente
1

La huella dactilar es de los parámetros de clave pública reales (es decir, el módulo RSA y cosas por el estilo). Sin embargo, el blob clave contiene muchos más datos que eso; tiene la identidad del usuario (nombre, correo electrónico, etc.) que se puede cambiar en una clave, y (la razón más común de una falta de coincidencia) tiene las firmas de otras personas. Las firmas no afectan las partes de la clave utilizadas para cifrar o verificar firmas, pero sí cambian el contenido del blob de clave.

Si tienes curiosidad, los blobs son básicamente certificados codificados en base64 (no estoy seguro de cuál es el formato decodificado real, algo binario como ASN1, pero puedes ver el texto ASCII de cosas como nombres y direcciones de correo electrónico dentro de ella).

    
respondido por el CBHacking 10.02.2017 - 11:27
fuente

Lea otras preguntas en las etiquetas