[kde-community] KDE Sysadmin and GPG Encryption

[Boudhayan Gupta]

Hi all,

After an email was sent to all developers with commit access on the
kde-cvs-announce mailing list with the new SSH host keys of the
machine, we've received complaints that the email contained sensitive
information and was not GPG encrypted.

We would like to say that GPG-encrypting the email would not have
added anything to the security of the email, and would have simply
been an added hassle. Because of the way GPG encryption is
fundamentally broken, we will *not* be encrypting any emails sent out
by us with GPG. A more detailed explanation follows.

1) The keys that we sent out were *public* keys. In asymmetric
cryptography, public keys are called public keys because they can be
known by the world - in fact, they *have* to be known by the world. In
simple terms, the public key is used to encrypt data; the private key
is used to decrypt data. Anyone can encrypt data and send it to
someone, but the recipient must have the private key in order to be
able to decrypt and read it. The private key is the key that has to be
kept secure, not the public key. There is no loss of security if the
public keys are disclosed. Therfore, encrypting the email to hide the
key from unintended recipients has no use.

2) GPG doesn't simply encrypt the email, but also digitally signs it.
Signatures are required to prove the authenticity of the email, and to
detect if it was tampered with. However, given our email
infrastructure, a GPG signature is meaningless. Anyone can create a
GPG key, encrypt the email and send it out. To trust the public key,
it would have to be either (a) distributed in a trustable way, which
brings us to the same sitation as the SSH host key, (b) signed by
another trusted entity (a person), after a face-to-face meeting, or
(c) signed by members of a web of trust (which recursively requires
one of (a) and (b)). Given we live in such physically diverse location
(in fact, Ben lives in New Zealand; meeting enough KDE contributors
face to face willing to sign his key is prohibitvely time, effort and
finance consuming). If you can't establish trust of a GPG public key,
the signature is meaningless.

3) We have a much stronger way of establishing the authenticity of the
email: DKIM. Both GMail and the KDE email servers publish DKIM public
keys through their DNS servers, and digitally sign every mail with a
DKIM signature. All major webmail providers and email clients *verify*
said DKIM signature automatically, and if it doesn't match, sends it
directly to Spam, with a visible warning saying the DKIM signature
could not be verified. You can inspect the headers of the email to be
sure it originated from a KDE server, and verify the DKIM signature to
authenticate the email.

4) The kde-cvs-announce email ID, in particular, is very secure. All
emails sent through that list have to be manually authorised. A random
person with the ability to send emails through KDE Postbox cannot
simply send an email as kde-cvs-announce.

5) If you don't trust your DNS provider and suspect that the DKIM
public key that you get via DNS has been tampered with, you can
independently verify it from our DNS server configuration, either by
resolving against byte.kde.org, or from the git repo at
git://anongit.kde.org/sysadmin/dns.git

As your system administrators, we take good care to ensure our systems
are not compromised, and the authenticity of our servers and messages
can always be verified. In between all the members of our team, we
have significant practical experience securing servers. I personally
have an academic interest in cryptography and information security,
especially in provable security. Importantly, this means we *know*
what cryptographic measures actually add to the security of our
systems, and which cryptographic measures only act to calm the
paranoid while adding absolutely no amount of additional security (and
this can be quantified, measured and mathematically verified, mind) to
our systems. We will do everything we can to improve our systems re.
the former point, but we will not implement any measure that simply
serve the latter point.

Thanks,
Boudhayan Gupta
KDE Sysadmin