Perché il "blocco chiave pubblico" è diverso, anche se l'impronta digitale è la stessa per le chiavi gpg

4

Sono nuovo di pgp & cercando di capire come funziona.

La chiave di firma di nginx è elencata qui: link

L'impronta è: 573B FD6B 3D8F BC64 1079 A6AB ABF5 BD82 7BD9 BF62

Se cerco la chiave di nginx su pgp.mit.edu , ricevo una chiave ascii dall'aspetto diverso la cui impronta digitale è la stessa di sopra.

Perché le "parti chiave pubbliche" sono diverse anche se le chiavi sono le stesse?

    
posta user 10.02.2017 - 10:48
fonte

3 risposte

2

L'impronta digitale di una chiave viene calcolata sulle parti di essa pertinenti per assicurarti di avere la chiave pubblica giusta.

Ma una chiave pubblica PGP può contenere più informazioni di quella; ad esempio, può contenere un'immagine di ritratto, può contenere firme di persone che si fidano della tua chiave, dei loro indirizzi e-mail e così via. L'ordine di questi elementi può cambiare senza modificare l'impronta digitale e se una chiave contiene un'immagine non fa nulla per cambiare l'impronta digitale, perché il ritratto o l'ordine in cui questi elementi sono memorizzati non è rilevante per l'autenticazione della chiave.

Quindi è probabile che il server delle chiavi modifichi alcune delle parti non rilevanti della chiave; quindi ottieni un altro blocco chiave, ma la stessa impronta digitale.

Immagina che qualcuno abbia incasinato la chiave di Bob sul keyserver per cambiare l'immagine del ritratto in essa contenuta. L'impronta digitale rimarrebbe la stessa perché, anche con il ritratto sbagliato, se Alice ha usato la chiave per crittografare un messaggio su Bob, potrebbe ancora essere decodificato dalla chiave privata di Bob.

Tuttavia, se Malory ha lasciato il ritratto di Bob da solo ma ha sostituito il modulo e l'esponente della chiave pubblica con il proprio, questo cambierebbe le impronte digitali, e giustamente: non sarebbe più la chiave di Bob, e criptare qualcosa con esso darebbe Accesso malato ad esso tramite la chiave privata di Malory.

Noi potremmo costruire l'impronta digitale su tutti gli elementi di una chiave pubblica, ad es. includendo tutte le firme e ulteriori informazioni personali sul proprietario della chiave, ma se ha funzionato in questo modo, ogni volta che hai aggiornato alcune informazioni banali nella tua chiave, o qualcuno ha aggiunto un'altra firma, la tua impronta digitale sarebbe cambiata, e avresti devi spiegare a tutti che no, la tua chiave non è stata violato, hai appena inserito una nuova immagine di ritratto in cui il tuo sorriso era più radioso.

    
risposta data 10.02.2017 - 11:30
fonte
2

Un blocco chiave GPG non è un singolo valore chiave ma consiste in più pacchetti di tipi diversi, seguendo il formato messaggio OpenPGP .

Nel tuo caso, entrambi i blocchi contengono lo stesso pacchetto chiave pubblica e ID utente ma la seconda chiave elenca alcuni strumenti aggiuntivi pacchetti di firma .

Puoi usare gpg(1) con --list-packets per enumerarli come segue:

$ 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]

Ora di nuovo con la chiave da 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]

Come puoi vedere, i pacchetti di chiavi pubblici di entrambi i blocchi hanno lo stesso ID della chiave ( ABF5BD827BD9BF62 ). La differenza di dimensioni è causata dai diversi pacchetti di firma mentre la chiave pubblica è identica.

    
risposta data 10.02.2017 - 11:48
fonte
1

L'impronta digitale è dei parametri della chiave pubblica effettiva (cioè il modulo RSA e cose del genere). Il blob delle chiavi contiene molti più dati di quello, però; ha l'identità dell'utente (nome, email, ecc.) che può essere modificata su una chiave e (il motivo più comune per una mancata corrispondenza) ha le firme di altre persone. Le firme non influiscono sulle parti della chiave utilizzate per la crittografia o la verifica delle firme, ma cambiano il contenuto del blob delle chiavi.

Se sei curioso, i BLOB chiave sono fondamentalmente solo certificati con codifica Base64 (non sono sicuro di quale sia il formato decodificato reale, qualcosa di binario come ASN1, ma puoi vedere il testo ASCII di cose come nomi e indirizzi email al suo interno).

    
risposta data 10.02.2017 - 11:27
fonte

Leggi altre domande sui tag