2

Public-Key servers should accept valid Public-Keys.

And they either cannot refuse to accept massive keys from a single IP, or from zombies, or from a hacked qualified key server via sync requests.

Generating some kinds of public key is quite quick, i.e., Ed25519: high-speed high-security signatures specifies:

Very fast signing. The software takes only 87548 cycles to sign a message. A quad-core 2.4GHz Westmere signs 109000 messages per second.
Fast key generation. Key generation is almost as fast as signing. There is a slight penalty for key generation to obtain a secure random number from the operating system; /dev/urandom under Linux costs about 6000 cycles.

Is it possible attack key servers with massive valid but frivolous Public-Keys continually, so that they cannot continue to work properly?

Either they go offline, or refuse to accept new public keys, or ban certain kinds of key generating algorithms, or delete all keys uploaded in a certain time, or requires registration or CAPTCHA.

And most importantly, how is Public-key Server system designed to be away from this kind of attack?


Edit: In 2014, Werner Koch submitted an I-D for use of Ed25519 in OpenPGP. I have no idea if it is accepted in OpenPGP, but ECC is supported.

As statistics from https://sks-keyservers.net/status/key_development.php says, there are 4.5 Million OpenPGP keys in total, though some sources claims more. Less than 1 thousand keys are added daily, with a maximum exception to be 40 thousand per day.

Since generating Ed25519 public keys is pretty easy, and the amount of public keys is rather small (I had expected it to be trillions in amount and pega-bytes to occupy), to double the keys in one day might not be a joke.

Even if the servers discard keys to avoid garbage outnumber good keys (I wonder if that is the case when negative amount of daily keys added occurs to the statistic), it means some good keys are discarded, too. And you can always perform a distributed attack at any time.

I have no idea if this conclusion applies to all ECC curves. Neither do I have any idea if RSA do, too, by generating weak keys (it doesn't matter even if they are easy to break). But I do wonder how PGP servers survived, as I am rather juvenile in this field.

5
  • 1
    There's a lot of quoting in your question, but no source has been identified for those quotes. Please add this to the question. Commented Aug 22, 2016 at 2:12
  • @MaartenBodewes The second comes from Ed25519: high-speed high-security signatures . The first and last are examples that I myself have come up with. Quoting should be regarded as annotations in these two cases.
    – Schezuk
    Commented Aug 22, 2016 at 7:02
  • @MaartenBodewes I appreciate that you taught me the correct way to express it. Some more edit was made in question.
    – Schezuk
    Commented Aug 22, 2016 at 14:38
  • @tylo Well, I have run out my quota posting one in security-SE today. And is key-managing part of design of cryptography?
    – Schezuk
    Commented Aug 22, 2016 at 14:43
  • 1
    @Schezuk Actually no, key management is part of IT security and not cryptography per se. However, this isn't about key management, either. I would consider this as a denial of service attack. And counter measures for that have nothing to do with cryptography at all.
    – tylo
    Commented Aug 22, 2016 at 15:49

2 Answers 2

8

This question really just boils down to, "Should you put rate-limits on a public-facing endpoint that accepts and records uploaded data from untrusted users?", to which the answer is virtually always "yes". There's nothing specific in this question that fundamentally ties it to public certificates.

4
  • But how did PGP design to limit it?
    – Schezuk
    Commented Aug 22, 2016 at 2:02
  • 1
    Again, this has nothing to do with PGP. You might as well ask how imgur prevents someone from uploading terabytes of images to their servers to waste disk space — there's nothing in HTTP to limit someone from doing this. It's not even clear that uploading a bunch of keys to a PGP server would do anything — it's not like there's a ton of processing being done server-side to decode a certificate; you're basically just uploading bytes and having them store it. And their storage is going to be infinitely cheaper than an attacker's outgoing bandwidth. Commented Aug 22, 2016 at 4:44
  • 2
    @StephenTouset Unless it's somebody else's bandwith, of course. Commented Aug 22, 2016 at 8:32
  • @StephenTouset Indeed, bandwidth of an attacker with zombies is hardly any problem. Bandwidth of the attacked server is. See edit in question.
    – Schezuk
    Commented Aug 22, 2016 at 14:40
1

The design of the key server network, which is mostly relied on for exchanging OpenPGP keys, does not protect at all against such attacks. It relies on replicating all information, and will fatally fail when an attacker starts flooding it.

You don't even need to do so by creating lots of keys. Adding a few keys with large image user IDs will be sufficient to blow up the total amount of information to be replicated and fill up the key server's hard drives.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .