Re: [Sks-devel] exchange of ideas

[brent s.]

On 3/22/19 9:16 PM, brent s. wrote:
> On 3/22/19 4:50 PM, fuat wrote:
>> Hi everybody,
>>
>> Is it a security threat to keep public keys in the sks database in the
>> directory as an .asc file?
>>
>> Can it be done? Why can not be done?
>>
>> What are the advantages and disadvantages?
>>
>> I'd appreciate it if you sent me your ideas.
>>
> 
> A *security* threat? As long as it's the public key, no.
> 
> But you don't really gain anything but problems from it, because:
> 
> - the ASCII-armored version of a key takes up more bytes in storage than
> the binary format (this is true of any binary => BASE64 conversion,
> especially with the headers that ASCII-armored format includes)
> 
> - the ASCII-armored version would need to be converted to binary anyways
> to properly be parsed by the underlying library (someone fact-check me
> on this, I'm about 80% certain on this)
> 
> - the underlying library can convert to ASCII-armored anyways for
> rendering to clients that request it


For clarification/demo purposes and to explain why this gives you
nothing beneficial, I've created a key using default options in a
pristine GPG home:

$ export GNUPGHOME='/tmp/gpg'
$ mkdir -p ${GNUPGHOME}
## initialize the new home and confirm there are no keys present.
## using gpg 2.2.13 with libgcrypt 1.8.4
$ gpg -k
$ gpg --full-generate-key

After the above:

$ gpg -k
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/tmp/gpg/pubring.kbx
--------------------
pub   rsa2048 2019-03-23 [SC]
      0C9968DDF66B002A83B166C213C4A28BE24D36F1
uid           [ultimate] testing key (DO NOT UPLOAD) (DO NOT UPLOAD)
<address@hidden>
sub   rsa2048 2019-03-23 [E]

$ gpg --export --armor 0C9968DDF66B002A83B166C213C4A28BE24D36F1 >
0C9968DDF66B002A83B166C213C4A28BE24D36F1.asc
$ gpg --export 0C9968DDF66B002A83B166C213C4A28BE24D36F1 >
0C9968DDF66B002A83B166C213C4A28BE24D36F1.gpg
$ ls -l 0C9968DDF66B002A83B166C213C4A28BE24D36F1.*
-rw-r--r-- 1 usernm grpnm 1782 Mar 22 21:26
0C9968DDF66B002A83B166C213C4A28BE24D36F1.asc
-rw-r--r-- 1 usernm grpnm 1255 Mar 22 21:26
0C9968DDF66B002A83B166C213C4A28BE24D36F1.gpg

As you can see, the binary format is approximately 70% the size on-disk
of the ASCII-armored version. This scales pretty well; generally
speaking, the binary format of any given signature, including signatures
or not, regardless of hash type or key size, will be roughly 70% the
size of the ASCII-armored equivalent data.

Let's continue:

$ gpg --list-packets 0C9968DDF66B002A83B166C213C4A28BE24D36F1.gpg |
sha512sum
dfb9eb884ca9491314dfced3a9e4fc5392af7742ae01cb1d468810606ce5cb40a60effefb0ac44d49beb7bffde0e5578a648cf50e059390dddc010a930f5646c
 -
$ gpg --list-packets 0C9968DDF66B002A83B166C213C4A28BE24D36F1.asc |
sha512sum
dfb9eb884ca9491314dfced3a9e4fc5392af7742ae01cb1d468810606ce5cb40a60effefb0ac44d49beb7bffde0e5578a648cf50e059390dddc010a930f5646c
 -

The packets contained in these files are exactly the same after parsing.
So what do those packets actually look like?

$ gpg --list-packets 0C9968DDF66B002A83B166C213C4A28BE24D36F1.asc
# off=0 ctb=99 tag=6 hlen=3 plen=269
:public key packet:
        version 4, algo 1, created 1553304360, expires 0
        pkey[0]: [2048 bits]
        pkey[1]: [17 bits]
        keyid: 13C4A28BE24D36F1
# off=272 ctb=b4 tag=13 hlen=2 plen=59
:user ID packet: "testing key (DO NOT UPLOAD) (DO NOT UPLOAD)
<address@hidden>"
# off=333 ctb=89 tag=2 hlen=3 plen=334
:signature packet: algo 1, keyid 13C4A28BE24D36F1
        version 4, created 1553304360, md5len 0, sigclass 0x13
        digest algo 8, begin of digest 38 b4
        hashed subpkt 33 len 21 (issuer fpr v4
0C9968DDF66B002A83B166C213C4A28BE24D36F1)
        hashed subpkt 2 len 4 (sig created 2019-03-23)
        hashed subpkt 27 len 1 (key flags: 03)
        hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
        hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
        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 13C4A28BE24D36F1)
        data: [2046 bits]
# off=670 ctb=b9 tag=14 hlen=3 plen=269
:public sub key packet:
        version 4, algo 1, created 1553304360, expires 0
        pkey[0]: [2048 bits]
        pkey[1]: [17 bits]
        keyid: 61271351C2DCBA83
# off=942 ctb=89 tag=2 hlen=3 plen=310
:signature packet: algo 1, keyid 13C4A28BE24D36F1
        version 4, created 1553304360, md5len 0, sigclass 0x18
        digest algo 8, begin of digest 8a 7a
        hashed subpkt 33 len 21 (issuer fpr v4
0C9968DDF66B002A83B166C213C4A28BE24D36F1)
        hashed subpkt 2 len 4 (sig created 2019-03-23)
        hashed subpkt 27 len 1 (key flags: 0C)
        subpkt 16 len 8 (issuer key ID 13C4A28BE24D36F1)
        data: [2046 bits]

As shown, the only real difference between the binary format and the
ASCII-armored format is that the ASCII-armored version is
human-readable. In fact, you can even do (assuming you're using GNU sed)
the following, and get *the same exact parsed results*:

$ sed -re '/^(\s*$|-----(BEGIN|END)|=)/d'
0C9968DDF66B002A83B166C213C4A28BE24D36F1.asc | base64 -d | gpg
--list-packets - | sha512sum
dfb9eb884ca9491314dfced3a9e4fc5392af7742ae01cb1d468810606ce5cb40a60effefb0ac44d49beb7bffde0e5578a648cf50e059390dddc010a930f5646c
 -

So as shown, the ASCII-armor is literally just a BASE64'd representation
(which is always larger than the input for binary data) of the binary
key.[0]


[0] *Technically* the correct terminology is "Radix-64", but there is
functionally no difference between BASE64 and Radix-64, just
nomenclature/context difference.
https://tools.ietf.org/html/rfc4880#section-6.2

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

signature.asc
Description: OpenPGP digital signature