Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We use GnuPG for encrypting data, which we upload to a central storage.

The public key is being stored on a web-server, and the encrypting script re-downloads it if it's changed. This was done in order to easily refresh the public key every so often on all the servers.

After some security thinking, I got the paranoia, that someone can (unlikely, but potentially), break into the web-server, and replace the public key with his own.

This would give 2 very unpleasant effects:

1) The hacker could read the data, if he manages to break out into the central storage as well.

2) Even if he doesn't - we won't be able to read the data as well as the private key got changed, and it all can be considered as lost!

Can someone advice how to prevent this threat, or perhaps suggest a more robust, but still convenient, key refresh approach?


share|improve this question
Maybe check if the key is signed by a trusted person? – grawity Jan 30 '10 at 20:35
Hi. Any quick steps how to do it? Thanks. – SyRenity Jan 31 '10 at 1:13
up vote 1 down vote accepted

Use a push model.

push has several advantages:

  • Take load from the central server (depending on how many clients at once might hit the server)
  • No key on the central server -- you can keep the key on an especially hardened box that can't be reached from the web
  • Are you sure the key distribution server is your problem. It's a public key. Note the public part of the keypair. Apart from that: distributing that key will make it available on any of the other servers. Why is the distribution server so much more likely to be attacked than any other server?

Then again:

If I understand correctly you are getting paranoid about someone getting access to the public key?

It's a public key, the public key doesn't give the potential attacker any possibility to read the data once it's encrypted and sent off to the server (assuming no bugs in the crypto-software).

The attack vector would be that someone breaks into one of the server sending data do the central storage and just DoSes it by injecting vast amounts of useless data thereby writing to the disk until it's full.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.