Confronto tra chiavi OpenPGP presumibilmente identiche e pubblicate attraverso canali diversi

4

versione di tldr: Quando provo a confrontare le chiavi pubbliche che dovrebbero essere per la stessa entità, le versioni che ottengo attraverso canali diversi NON sono le stesse e quelle che ho scaricato come file come somekey.sig.asc sono file più piccoli.

Sto cercando di imparare l'intera cosa gpg e di esercitarmi correttamente. Un passaggio cruciale consiste nel verificare che una chiave pubblica appartenga effettivamente alla parte che si suppone. In assenza di una catena di contatti personali, la cosa ovvia è ottenere copie multiple da fonti diverse e verificare che siano identiche. Non riesco mai a farlo. Sospetto che parte del problema risieda in newline, carriagereturns, spazi, tabulazioni e altri personaggi inventati dallo SCOPTDUI (Consapevolezza segreta dei programmatori per far impazzire gli utenti). Ecco un esempio in cui sono abbastanza sicuro che i tasti SONO identici, ma non riesco a trovare una procedura per dimostrarlo.

Chiave del team Veracrypt dal server delle chiavi del MIT: link

Chiave del team di Veracrypt dal sito di Veracrypt: link

Ho scaricato entrambi direttamente. Ho copiato e incollato entrambi in file di testo. Ho spogliato i preamboli e le terminazioni, lasciando blocchi che iniziano tutti con lo stesso incomprensibile e finiscono con lo stesso incomprensibile.

Li ho eseguiti attraverso tutti i tipi di tr filtri, come:

cat file | tr -d '0125' > file-tred

Quello del MIT è ancora un file molto più grande. Li ho caricati in gedit e posso copiare pezzi sostanziosi di uno e cercare quel pezzo nell'altro e trovare una sottostringa identica, ma non con l'intero file.

Questo non è un esempio isolato. Il MIT non è unico. Il secondo server di chiavi che ho controllato (in Nuova Zelanda, ma non sono autorizzato a pubblicare un terzo link qui) ha lo stesso problema. Né Veracrypt è un caso speciale. Mi sono imbattuto in questo ogni volta che ho deciso di imparare a fare gpg il "modo giusto" e di battere la testa contro lo stesso muro per alcuni giorni prima di arrendermi. C'è qualche ragione per cui queste cose non sono pubblicate in un formato standard? C'è un modo per renderlo facile? Mi manca qualcosa di ovvio? Cosa rende questo file MIT così grande?

Addendum: In pratica:

gpg --keyserver address.like-this-with-no-protocol-prefix-and-no-trailing-slash.net --search SOMETHING

sembra controllare i duplicati delle chiavi che ho già e segnalare "nessun cambiamento", a condizione che scelgo SOMETHING bene. Quindi, funzionalmente, immagino che questo sia ok. Mi piacerebbe ancora sapere perché i miei confronti manuali falliscono.

    
posta Lew Rockwell Fan 18.01.2016 - 00:47
fonte

2 risposte

4

Un file di chiavi PGP non è una singola stringa di chiavi , ma contiene diverse voci (pacchetti). Invece di provare a confrontare la rappresentazione ASCII di entrambi i file, dovresti utilizzare strumenti appropriati come gpg(1) e confrontare le impronte digitali .

Is there some way to make this easy?

Sì, come questo:

$ wget https://www.idrix.fr/VeraCrypt/VeraCrypt_PGP_public_key.asc
$ gpg --with-fingerprint VeraCrypt_PGP_public_key.asc
pub  rsa4096/54DDD393 2014-06-27
      Key fingerprint = 993B 7D7E 8E41 3809 828F  0F29 EB55 9C7C 54DD D393
uid                   VeraCrypt Team <[email protected]>

L'impronta digitale visualizzata deve essere uguale per entrambi i file. Nota, come i pochi bit inferiori dell'hash rappresentano l'ID della chiave ( EB559C7C54DDD393 ).

Is there some reason these things aren't published in a standardised form?

Lo sono, dai un'occhiata a RFC 4880 per il formato di messaggio OpenPGP specifica.

What makes that MIT file so big?

Contiene molto più pacchetti di firma . Di nuovo, da RFC:

An OpenPGP message is constructed from a number of records that are traditionally called packets. An OpenPGP message, keyring, certificate, and so forth consists of a number of packets.

Puoi elencare tutti i pacchetti in un file tramite --list-packets (o usare pgpdump(1) per una versione più leggibile).

$ gpg --list-packets VeraCrypt_PGP_public_key.asc

Questo produrrà un'enumerazione come questa:

# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
    version 4, algo 1, created 1403892630, expires 0
    pkey[0]: [4096 bits]
    pkey[1]: [17 bits]
    keyid: EB559C7C54DDD393
# off=528 ctb=b4 tag=13 hlen=2 plen=35
:user ID packet: "VeraCrypt Team <[email protected]>"
# off=1137 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid D6BE7DAF738161CE
    version 4, created 1403950017, md5len 0, sigclass 0x10
    digest algo 2, begin of digest 08 92
    hashed subpkt 2 len 4 (sig created 2014-06-28)
    subpkt 16 len 8 (issuer key ID D6BE7DAF738161CE)
...

Come puoi vedere, il pacchetto di chiavi pubblico ha l'ID della chiave familiare EB559C7C54DDD393 , mentre i pacchetti di firma vengono con l'ID della chiave dell'emittente corrispondente (che puoi anche cercare il keyserver).

Nota a margine: ciò che chiami "preambolo" è chiamato armatura ASCII e usato per trasferire messaggi PGP su canali che hanno difficoltà con dati binari arbitrari (es. e-mail). Fa parte del formato e puoi lasciarlo nel file.

    
risposta data 18.01.2016 - 05:21
fonte
2

tl; dr: entrambi i dump contengono le stesse chiavi, ma ottieni alcune certificazioni aggiuntive dal server delle chiavi non incluso nell'esportazione minima del sito web VeraCrypt.

Pacchetti OpenPGP

Le chiavi OpenPGP sono composte da un insieme di pacchetti OpenPGP , che possono essere elencati in gpg --list-packets e pgpdump . Per le chiavi esportate, c'è un pacchetto richiesto, public key packet . Sneak peak (spiegazione seguente di seguito): questo è lo stesso per entrambe le chiavi.

:public key packet:
  version 4, algo 1, created 1403892630, expires 0
  pkey[0]: [4096 bits]
  pkey[1]: [17 bits]
  keyid: EB559C7C54DDD393

Una chiave è difficilmente utilizzabile senza pacchetti di ID utente. Non può essere interrogato da un nome e non può nemmeno ricevere certificazioni (le firme sulle chiavi puntano a tuple di impronte digitali e ID utente a chiave pubblica).

:user ID packet: "VeraCrypt Team <[email protected]>"

Infine, di solito viene emessa una firma personale. I server chiave spesso negano il caricamento delle chiavi senza auto-firma.

:signature packet: algo 1, keyid EB559C7C54DDD393
  version 4, created 1403892630, md5len 0, sigclass 0x13
  digest algo 2, begin of digest 7f 33
  hashed subpkt 2 len 4 (sig created 2014-06-27)
  hashed subpkt 27 len 1 (key flags: 0F) 
  hashed subpkt 11 len 6 (pref-sym-algos: 9 8 7 3 2 1)
  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 (key server preferences: 80) 
  subpkt 16 len 8 (issuer key ID EB559C7C54DDD393)
  data: [4096 bits]

Esportazione minima

Questa è la parte minima più o meno richiesta delle chiavi per essere utilizzabile. Per ciascuno degli ID utente, facoltativamente, è possibile aggiungere un elenco di certificazioni in entrata, per aiutare gli altri a verificare la chiave. Questa è la ragione più probabile per diversi output.

Confronto tra i tasti

Ora, come confrontare i tasti? Prima di tutto, consente di recuperarli entrambi in file locali mit.asc e veracrypt.asc . diff in quelli sarebbe il modo generale di confrontare i file, ma i file OpenPGP sono difficilmente leggibili, quindi cerchiamo di elencarli prima e quelli che li riguardano:

gpg --list-packets mit.asc >mit.asc.list
gpg --list-packets veracrypt.asc >veracrypt.asc.list
diff mit.asc.list veracrypt.asc.list

Il diff rivela molte firme aggiuntive nel dump del server delle chiavi. Guardando veracraypt.asc.list , sembra infatti che veracraypt.asc sia una versione minima, quindi lascia che l'utente delle opzioni di esportazione di GnuPG crei una copia minima di mit.asc :

gpg --dearmor mit.asc # Dearmor first, to use it as keyring file
gpg --export-options export-minimal --no-default-keyring --keyring ./mit.asc.gpg \
    --export 0xEB559C7C54DDD393 >mit-minimal.asc
gpg --list-packets mit-minimal.asc >mit-minimal.asc.list

Diffing ora rivela che veracrypt.asc contiene esattamente una firma aggiuntiva:

:signature packet: algo 1, keyid D6BE7DAF738161CE
  version 4, created 1403950017, md5len 0, sigclass 0x10
  digest algo 2, begin of digest 08 92
  hashed subpkt 2 len 4 (sig created 2014-06-28)
  subpkt 16 len 8 (issuer key ID D6BE7DAF738161CE)
  data: [4091 bits]

Una firma che afferma di appartenere all'autore di VeraCrypt (non ho convalidato la chiave, però).

    
risposta data 18.01.2016 - 10:49
fonte