[Popcon-developers] encrypted popcon submissions
On Sat, May 11, 2013 at 11:43:25AM +0200, Bill Allombert wrote:
> On Fri, May 10, 2013 at 10:44:25PM +0200, Peter Palfrader wrote:
> > On Fri, 10 May 2013, Bill Allombert wrote:
> >
> > > I am considering activating encryption of popularity-contest submissions
> > > using public key cryptography to protect popcon submission while in transit.
> >
> > Do you think the benefits outweight the drawback that the admin no
> > longer can be certain we don't send anything we shouldn't?
>
> I do not think it makes much difference. The report is sent by a simple shell script
> which you can easily audit. Even if you use a network scanner, you can check that
> what is sent is the encrypted file since you have a copy of it.
>
> And in any case, there will be an option do deactivate encryption if you so chose.
>
> > > - The popcon.debian.org server will know the matching private key and use it to
> > > decrypt report before storing them.
> >
> > > The drawback is the computing cost on the server. Currently we are processing
> > > about 25000 report each days, which would require about 2 hours of 'real'
> > > CPU time to decrypt, which is too much for popov.debian.org. On the other hand
> > > this is easily parallelisable.
> >
> > Why do you think this is too much for popov to handle?
>
> I did some benchmark. Currently popov CPU has about 20% of a real CPU.
> Currently processing the popcon data takes between 6h30 and 8h30.
> At this rate decrypting the report would take an additional 7h.
>
> > And if it really is, adding vCPUs is easy.
>
> Excellent.
>
> > Why is transport encryption (ala https) not sufficient?
>
> I do not see why https would be faster than gpg for the same level of security.
>
> There are some issues with https:
> 1) https does not handle email submissions. gpg is transport agnostic.
> 2) https requires more client-side support than what perl-base provide.
> On the other hand, apt already depends on gpg, so we can assume that gpg is
> available.
> 3) managing https certificate is harder. A gpg public key can easily be included
> in the popularity-contest package
On the other hand it can not as easily be changed when the private key
is compromised. The window between the hack being detected and data
being secure again would be far greater with a gpg key in the package.
> 4) https allows the web server to see the decrypted content. gpg encryption
> only allow the popcon user to read it.
> 5) https require CPU time when the reports is received. At time where a lot of
> reports are received at the same time, this can overload the CPU. By contrast,
> gpg provides much flexibility in CPU time allocations.
>
> Cheers,
MfG
Goswin
Reply to: