gpg --armor --export-secret-key si differenziano sugli ultimi 4 caratteri

Question

gpg --armor --export-secret-key si differenziano sugli ultimi 4 caratteri

#1 da (0 voti)

2

Ho creato un backup di una chiave gpg eseguendo:

gpg -a --export-secret-keys foo@bar > private.key
gpg -a --export foo@bar > public.key

Quindi su un altro sistema, li imposto:

gpg --import private.key
gpg --import public.key

Mi sono fidato della chiave come ultima, e il backup sembra funzionare, l'unica cosa che noto è che quando si fa:

gpg --armor --export-secret-key foo@bar

Gli ultimi 4 caratteri differiscono per esempio:

dutrV4c4hoPc6ntI3n9VztsL4LmmvoCcH969nJD6bTh4H1VMH98r8zECshtCSfVE
tMIIhXjA9xO1IZ6vMqHJU8TNhV2ttOE1Z/sUjcB46X4=
=TGyi
-----END PGP PRIVATE KEY BLOCK-----

Nel nuovo computer:

dutrV4c4hoPc6ntI3n9VztsL4LmmvoCcH969nJD6bTh4H1VMH98r8zECshtCSfVE
tMIIhXjA9xO1IZ6vMqHJU8TNhV2ttOE1Z/sUjcB46X4=
=/eDz
-----END PGP PRIVATE KEY BLOCK-----

Ti stai chiedendo perché gli ultimi caratteri differiscono, in questo caso =TGyi e =/eDz

gnupg

posta nbari 15.08.2018 - 22:52

fonte

1 risposta

Leggi altre domande sui tag gnupg

Perché il server di posta di hotmail fornisce un certificato non valido? Vulnerabilità HTML da modulo a PDF

score 0 · Answer 1

ALL'ARMATICA ASCII! - RFC 4880 . La specifica ARMII ASCII è fornita in Sezione 6.2 :

Concatenating the following data creates ASCII Armor:

An Armor Header Line, appropriate for the type of data

Armor Headers

A blank (zero-length, or containing only whitespace) line

The ASCII-Armored data

An Armor Checksum

The Armor Tail, which depends on the Armor Header Line

Quindi gli ultimi 5 caratteri ( =TGyi e =/eDz ) sono un checksum dei dati corazzati. Stranamente la Sezione 6.2 non definisce il formato del checksum, ma una versione precedente della specifica, la Draft di Internet del 1995 per PGP , fa:

The Armor Checksum is a 24-bit CRC converted to four bytes of radix-64 encoding, prepending an equal-sign (=) to the four-byte code.

I checksum sono usati in un certo numero di altri posti è il RFC, sempre definito come somma di due ottetti modulo 65536:

Then a two-octet checksum is appended, which is equal to the sum of the preceding session key octets, not including the algorithm identifier, modulo 65536.

Sembra un po 'strano che due copie degli stessi dati abbiano checksum differenti, ... forse c'è abbastanza ambiguità nelle specifiche che le diverse versioni di openpgp usano metodi diversi per calcolare il checksum?

(Disclaimer: questa è la mia prima volta che mi tuffo nelle specifiche PGP, forse qualcuno che ha più familiarità con esso può spiegare correttamente)