Author Topic: kbx.trid.xml for GPG keybox database  (Read 884 times)

jenderek

  • Sr. Member
  • ****
  • Posts: 375
kbx.trid.xml for GPG keybox database
« on: May 26, 2023, 11:37:26 PM »
Hello trid users,

some days weeks i must reinitialize a GPG system on a new installed
system (Linux Mint 21.1) and something is not working as expected.

I am astonished and shocked because Linux Mint is described as one of
the best distributions because it should be very user friendly. I have
installed GNU Privacy Assistant (gpa), KGpg (KDE GUI for GPG),
Kleopatra and corresponding libraries and command line tools, but the
context menus in file mangers are not working correctly. Sometimes the
context menu item for verifying Open-PGP signatures (*.asc *.sig
*.sign) is missing or the suited application starts but is not able to
fetch the used public keys. For comparison reasons i tried the same
things on current Raspberry PI OS, which is the standard for such arm
processors, but there the same problems arise.  I am often complaining
Microsoft but there the "same" software packages installed works
better. Hello Linux developers: "So you can not persuade Windows
desktop user to switch to Linux". What a shame!

Everywhere is said that security is important, but why are things so
complicated?  Instead of wasting money, time and resources for KI so
companies and organizations first should do more efforts in basic
security IT aspects. Since Putin's war against the Ukraine everyone
should be aware that tomorrow in your country war can begin which in
current times may start first as cyber war.

So i look on my systems for PGP signature and keys. For some parts the
file name suffix like KBX is used.

So i run trid utility on such KBX files. The samples are described
wrong as "Adobe PhotoShop Brush" by abr.trid.xml (See appended
output/trid-v-old.txt).

For comparison reason i also run the file format identification
utility DROID ( See https://sourceforge.net/projects/droid/). Here the
examples are also not recognized.

For comparison reason i also run file command (version 5.44) on such
samples. Here the samples are recognized and described as "GPG keybox
database". Also some details are shown like "version 1", created-at
and last-maintained time stamps (see appended output/file-i-5.44.txt).
Unfortunately no file name suffix is shown (see appended
output/file-ext-5.44.txt) and only generic application/octet-stream is
shown (see appended output/file-i-5.44.txt)

Luckily the file command sources list a page with c-source
keybox-blob.c on gnupg.org web site where file format is explained. So
this now used as reference URL. That is expressed by line like:
 <RefURL>
 https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=kbx/keybox-blob.c
 </RefURL>

Astonishingly for many PGP parts like older keys storage pubring.gpg
there exist an official mime type application/pgp-keys, but for KBX i
do not found a type. So i choose a similar user defined one. That is
expressed by line like:
   <Mime>application/x-pgp-keys-database</Mime>

So now i approximately know what patterns should appear in TrID
definition. Then i run tridscan on such KBX samples to generate trid
definition. Then i look inside definition for patterns and try to
understand why things happens. After some efforts i found a minimal
sample which apparently consist of just the header part. So the size
is just 32 (20 hexadecimal). So many pattern at higher offsets
vanished.

At offset 0 the length of this blob is stored as u32. Apparently this
20 hexadecimal. Afterwards the blob type is stored as bytes. For first
blob the value is always 1. Afterwards the version number is stored as
byte. In my examples this was always 1. I do not know if higher
version number exist. So just in case in mention this observation in
the remark line. Afterwards the Header flags are stored as u16 and
only bits 0 and 1 are used. So apparently the upper bits are unused
and in my examples these bits are 0. So these observations are
expressed by first XML construct like:
   <Bytes>00000020010100</Bytes>
   <Pos>0</Pos>

At offset 8 the Magic string 'KBXf' is stored. Afterwards RFU is
stored as u32. I do not know what RFU is, but in my examples this
value was nil. So these observations are expressed by second XML
construct like:
   <Bytes>4B42586600000000</Bytes>
   <ASCII> K B X f</ASCII>
   <Pos>8</Pos>

At offset 16 the time stamp for created is stored as u32.  At offset
20 the time stamp for last maintained is stored as u32.

At offset 24 the next 2 RFU are stored, in my examples this value was
nil. So i mention this in remark line.  So these observations are
expressed by third XML construct like:
   <Bytes>0000000000000000</Bytes>
   <Pos>24</Pos>

These informations can be verified partly by gnupg-utils command like:
     kbxutil ./pubring.kbx
This gives an output like:
BEGIN-RECORD: 0
Length: 32
Type:   Header
Version: 1
Flags:   0002 (openpgp)
created-at: 1684189781
last-maint: 1684189781
END-RECORD

Such files are by default are found in directory ~/.gnupg if not
another directory is given by --homedir option, environment variable
GNUPGHOME or Windows registry entry HKCU\Software\GNU\GnuPG:HomeDir.
The file name is pubring.kbx. For temporarily and backup purpose also
pubring.kbx~ pubring.kb_ and maybe pubring.k__ are used (for later
case i myself do not found an example). I also do not know under which
conditions these are generated or used. So i mention these facts by a
remark line. So the different file names are expressed inside
definition by line like:
   <Ext>KBX/KBX~/KB_</Ext>

With the new trid definition such GPG keybox databases are now
described (see appended output/trid-v-new.txt). TrID definitions, few
samples and output are stored in archive kbx_2.zip. I hope that my
definition can be used i future version of triddefs.

With best wishes
Jörg Jenderek


Mark0

  • Administrator
  • Hero Member
  • *****
  • Posts: 2744
    • Mark0's Home Page
Re: kbx.trid.xml for GPG keybox database
« Reply #1 on: May 26, 2023, 11:43:37 PM »
Thanks!