how to encrypt a file using private key in gpg

Question

I'm producing an update for some systems and I want to encrypt the updates for keeping confidentiality, integrity and validity of my signature. I want to encrypt the file with my private key and send them to my client so that they can decrypt it with my public key. But the way GPG works is encryption with public and decrypt with private. I don't want to send my private key so that I can change it and send public key to anyone else . Any idea how to do that???

Answer 1

What you mean is not called "encryption" but "signing" in gpg lingo.

Signing is basically encrypting with your private key and decrypting with the public key.

Use

 gpg --sign myfile.ext

Or use your email-client's signing capabilities.

Signing will obviously allow anybody who has access to your "public" key to read the contents of your file (and since a "public" key is usually, well..., public, this will allow everybody to decypher the content).

If you are looking for a method, where only the recipient can decode the content, then you need to encrypt the data in a way where only the recipient has access to the decrypting token. obviously the recipient need to have such a token (that is: you encode with their public key, so they can decode with their private key)

UPDATE

To make it simple: if you want to guarantee integrity (that is: the recipient knows for sure, that the data comes from you and nobody else), you need to sign the data. If you want to guarantee confidentiality (that is: only your recipient can read the data), you need to encrypt the data.

Both signing and encryption are really the same thing. The only difference is, who has access to the keys.

With signing, you use your private key to encrypt the data, and it can be decrypted with your public key (and since everybody has access to the public key, everybody can decrypt it, and thus everybody can validate that the data has been signed by you)

With encrypting, you use your recipients public key to encrypt the data, and they use their private key to decrypt it (so only they can read it; but everybody can send them an encrypted datum, they have no guarantee that it really comes from the sender, but it is guaranteed that only they can read it).

If you need both confidentiality and integrity, you need to do both signing and encryption, and for this to work, both you and your recipients need to have a (different) public/private key pair.

CONCLUSION

Since both signing and encrypting are the same thing, you can use both to guarantee validity and integrity of your data, as long as you have full control over the availability of the keys involved.

Answer 2

I am working on a similar problem: distribute software updates from a central source to be applied to many end-users in the field. End users need to validate that the update came from the official source (signed with private key), but I also want the update to travel confidentially (encrypted).

In the cryptography course I had at University ~30 years ago now, they taught that encrypting with one's private key was the same thing as signing a message - when the recipient decrypts using the public key, the fact that they do not get gibberish confirms use of the private key to encrypt. This also provides a measure of confidentiality if the public key is kept "close to the vest," which would be my preferred implementation.

As mentioned by others, I have confirmed that the gpg --sign operation does not encrypt the message, the message is visible in plaintext in the signed file. To use gpg to accomplish both certain authenticity with a signature from the private key, and a reasonable measure of confidentiality, I have settled on the solution of giving the field based receivers their own key pair, in addition to the public key of the update distributor. This isn't a terribly secure solution, anyone can reverse engineer a device in the field and get ahold of the "secret" key that it will hold, with that they can decrypt the signed update message and see its cleartext contents. What they cannot do is create a file with the distributor's secret key signature on it, and so they cannot make an update of their own that will be accepted by the devices in the field which are looking for both encryption with their public key, and a signature from the update distributor's privately held key.

It's a matter of degrees of exposure. The updates in transit are secure from anyone who does not have access to an endpoint device to reverse engineer. With physical access to an endpoint (something we cannot prevent), they will eventually be able to reverse engineer the installed software, and even the updates themselves, but they will never be able to sign their own update and push it to un-compromised machines. At least as long as RSA is secure.