sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] exchange of ideas


From: fuat
Subject: Re: [Sks-devel] exchange of ideas
Date: Sat, 23 Mar 2019 06:20:53 +0300
User-agent: Evolution 3.30.1 (3.30.1-1.fux1)

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
> address@hidden
> 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.
-- 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]