gnupg - need to be able to decrypt, without being able to encrypt

1
votes

What I need to do is this:

  • at my server: get a file and encrypt
  • at many remote devices, I need to decrypt the file (don't need to check autenticy/signature)

I can't give the remote devices the hability to encrypt!

What I did -- Step 1 -- key preparation:

  • at my notebook:
  • gpg --gen-key
  • gpg --armor --export KEYNUMBER > key.pub

  • gpg --armor --export-secret-key KEYNUMBER > key.priv

  • at my server:

  • gpg --import < key.pub

  • at remote devices

  • gpg --import < key.priv

What I did -- Step 2 -- encrypt the file:

  • at my server:

  • gpg --armor --encrypt --recipient KEYNUMBER < file.orig > file.asc

  • at remote devices

  • gpg --decrypt < file.asc > file.out

All works OK this way. As I wished.

But, If I do at remote devices "gpg --armor --encrypt --recipient KEYNUMBER < file.orig > file.asc" this generates sucessfully. I don't want the remote device to be able to encrypt. It is supposed only to decrypt.

Any hints about how to solve this?

Thanks,

2
encryptioncryptographygnupg
For future questions, have a look on how to format code – maybe have a look at the FAQ. – Jens Erat
Which security properties do you expect out of "private key encryption" that signatures do not have? – CodesInChaos

2 Answers

3
votes

You cannot prevent the clients being able to encrypt to that key, as the secret key always includes the public key in OpenPGP (which is implemented by GnuPG).

From RFC 4880, highlighting added by me:

5.5.1.3. Secret-Key Packet (Tag 5)

A Secret-Key packet contains all the information that is found in a Public-Key packet, including the public-key material, but also includes the secret-key material after all the public-key fields.

5.5.1.4. Secret-Subkey Packet (Tag 7)

A Secret-Subkey packet (tag 7) is the subkey analog of the Secret Key packet and has exactly the same format.

If you want to make sure a message was sent from the server, you will have to sign it using a second key pair, where the server has the private key and the clients only the public one.

1
votes

You should ask yourself why you don't want the remote device to be able to encrypt. On the one hand you say that you don't need authentication, but OTOH you probaly want to achieve some kind of authentication by ensuring that only the server is able to encrypt. So if you need authentication and integrity protection, use the mechnisms that are designed for it, namely digital signatures. If you don't need authentication, don't worry about the devices being able to encrypt messages.