exchange of ideas

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

exchange of ideas

fuat
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.

--
┌------------------------------------------┐
| Fuat Bölük  fuat[at]teknoloji360[dot]com |
|------------------------------------------|
|------ hkps://sks.teknoloji360.com/ ------|
|------------------------------------------|
| F0D4521D60378B67CE64665EE7C9735903E48A51 |
└------------------------------------------┘
--
 I do not know english. I'm using translate.
--


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: exchange of ideas

brent s.
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


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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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)
<[hidden email]>
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)
<[hidden email]>"
# 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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: exchange of ideas

brent s.
On 3/22/19 9:44 PM, brent s. wrote:
(SNIP)
> 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.
(SNIP)
SIGH.


"the binary format of any given signature, including signatures or not,
regardless of hash type or key size,"

should read:


"the binary format of any given *exported key*, including signatures or
not, regardless of hash type or key size,"

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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: exchange of ideas

fuat
In reply to this post by brent s.
I thought it was more comprehensive.

Let me explain.

A text file, html file, and .asc file are not dangerous to the server.

The attacker cannot harm the server with the text file. can only read.
but sks database is very often corrupted. If there is an error in
writing a file, only that file is corrupted.

The content of a text file from the internet is quick to reach.

all keys or over 500 keys do not overload the server unless requested
at one time. already sks software also outputs single key.

The database occupies only 20 percent less disk space and the search is
slightly faster than 20 percent.

sks KDB 18G
5.500.000 readeable .asc files 25G

however, instead of remaining dependent on a single system for such a
difference, it would be more flexible and diverse to work with
different programs that achieve the same results and do the same.

only molds are decided jointly, and each program produces the
appropriate output to the same pattern.

it doesn't matter if you get to an address with firefox, opera or
chrome, the important thing is that the address you enter is the same.

Cum, 2019-03-22 tarihinde 21:16 -0400 saatinde, brent s. yazdı:

> 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
>
>
> _______________________________________________
> Sks-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/sks-devel
--
┌------------------------------------------┐
| Fuat Bölük  fuat[at]teknoloji360[dot]com |
|------------------------------------------|
|------ hkps://sks.teknoloji360.com/ ------|
|------------------------------------------|
| F0D4521D60378B67CE64665EE7C9735903E48A51 |
└------------------------------------------┘
--
 I do not know english. I'm using translate.
--


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: exchange of ideas

brent s.
Whoops, sent a direct reply instead of to the list. Pasted below.

On Mar 22, 2019 23:20, fuat <[hidden email]> wrote:

I thought it was more comprehensive. 

Let me explain. 

A text file, html file, and .asc file are not dangerous to the server. 


Which is what I assert in my first reply, yes.


The attacker cannot harm the server with the text file. can only read. 
but sks database is very often corrupted. If there is an error in 
writing a file, only that file is corrupted. 


Hasn't happened to me in the two? Three? Years I've been a public pool member. DBs also have a more robust journaling than flat filesystem backends, which you're ignoring.


The content of a text file from the internet is quick to reach. 


Do you plan om doing a google search against a BASE64 snippet instead of a key attribute? I fail to understand the relevance of this.


all keys or over 500 keys do not overload the server unless requested 
at one time. already sks software also outputs single key. 

Unless a recon peer, or a multiple-match search which will return references to other keys.


The database occupies only 20 percent less disk space and the search is 
slightly faster than 20 percent. 

sks KDB 18G 
5.500.000 readeable .asc files 25G 

however, instead of remaining dependent on a single system for such a 
difference, it would be more flexible and diverse to work with 
different programs that achieve the same results and do the same. 


No, it wouldn't, because there is no RFC for this. There is for OpenPGP, which is precisely why it's used.


only molds are decided jointly, and each program produces the 
appropriate output to the same pattern. 

it doesn't matter if you get to an address with firefox, opera or 
chrome, the important thing is that the address you enter is the same. 


Again, your proposed method breaks PGP/GPG, which is the entire reason the SKS pool exists.


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: exchange of ideas

Steffen Kaiser
In reply to this post by fuat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 23 Mar 2019, fuat wrote:

> A text file, html file, and .asc file are not dangerous to the server.
>
> The attacker cannot harm the server with the text file. can only read.
> but sks database is very often corrupted. If there is an error in
> writing a file, only that file is corrupted.

if a single file gets corrupted, you won't notice. If the DB is corrupted,
you'll notice soon. A single file is more easily compromised.

> The content of a text file from the internet is quick to reach.

Yes, if you have a straight forward access mechanism, e.g. getting by hash
or an exact match lookup. You can surf many many static files easily -
semiparallel. But what about (fuzzy) search? You'll need some sort of
search index to answer in a reasonable time. The same key can be addressed
by different lookup queries, too.

> The database occupies only 20 percent less disk space and the search is
> slightly faster than 20 percent.

I'll doubt that non-exact search is only 20% faster than handling plain
text files.

> however, instead of remaining dependent on a single system for such a
> difference, it would be more flexible and diverse to work with
> different programs that achieve the same results and do the same.

Yes. In fact, you could do so now by using SKS for reconcil only, dump the
keys in any fashion and use yet another search and delivery program.

If you increase logging, you'll get Adding Del'ing lines. I assume these
include update events, too.

- --
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBXLA3aiOjcd6avHZPAQKjLAgAhKb/b4L1qojsV79UP2EW+g3J2JV/Ce1y
Rv/0AFo9qeX8JGAiErh10G+OVI09/3GMaKLCJrFKbpXcqC+XU7ZyPxGidfAsYtuf
TT93S2pCyelsZo7QLMNqquSXoSCGeEQ2M5yVONKWJliQnOq4T1i8yrSQDFepU1K5
G7nW+A3DcmONl2BjFaQHFUqTQlg/EmOFdUVHzzoKe264Wm0ycYXUS+SUwoT8b1wa
7F5gAAHMToh6+jA9TpmbUckcRWhZyHVGjCvV4lwnV81dpduoI7b+PjkiSt7Aa7rK
o2+WiirXYzHYAcPTRXTxsHj+bS3//F8VPu3RhGZUZ44ZzLx3UPQunA==
=JHkw
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel