6

I am using gpg to encrypt and decrypt a file. Here are the steps I am doing taking reference from this question:

# Sender
gpg --encrypt --recipient recipient@gmail.com --output confidential.pgp confidential.txt
gpg -–sign –-local-user sender@gmail.com --output signed.pgp confidential.pgp

# Recipient
gpg --decrypt –output confidential.pgp signed.pgp 
gpg --decrypt –output confidential.txt confidential.gpg

It works, but is this the correct way to encrypt, sign and decrypt a file if the signature verification has to be made mandatory at the recipient end? Especially, decrypting twice seems a bit odd. Can this be done in a single command?

I tried using --signdirectly in the encryption command, but it just warns and decrypts the file which doesn't satisfy the mandatory signing requirement. Here is the official manual, but it doesn't talk about doing everything in a single step.

# Sender
gpg -–sign –-local-user sender@gmail.com --encrypt --recipient recipient@gmail.com --output signed.pgp confidential.txt

# Recipient
gpg --decrypt –output confidential.txt signed.pgp

Update 1

After some research, I found a very related question which seems to indicate that gnupg --sign --encrypt first signs and then encrypts a document. So we will have to decrypt it first anyway to see the document. It can optionally output the status using --status-fd which can be used to check if the signature is fine using a simple script. So the code would look like:

# Sender
gpg -–sign –-local-user sender@gmail.com --encrypt --recipient recipient@gmail.com --output signed.pgp confidential.txt

# Recipient
gpg --decrypt --status-fd –output confidential.txt signed.pgp | verify

where verify is a shell script that checks the status registers and aborts if required.

Nishant
  • 165
  • 1
  • 7
  • 4
    As far as I am aware, you cannot _force_ the recipient to verify the signature. You can only provide them with the signature and hope that they care to verify it. – forest May 18 '18 at 08:57
  • Thanks @forest. If I can't force it from the sender side, is it possible to use any options at the client side such that if it fails, I don't read it? That should suffice too. – Nishant May 18 '18 at 09:06
  • 3
    Perhaps use `--verify` and only `--decrypt` if the former command succeeds? – forest May 18 '18 at 09:08
  • @forest, Hope I can rely on the exit status of `--verify`. The workflow of encrypt -> sign -> verify -> decrypt -> decrypt is OK? I have to decrypt twice to see the content. If I do `--encrypt` and `--sign` in one step I can't validate, probably because it signs first and then encrypts? – Nishant May 18 '18 at 15:24
  • 2
    You want to do sign and encryption together, e.g. `gpg --sign --encrypt`. And yes, you can rely on the exit status of `--verify` (at least for `-qqv`, which silently verifies before returning 0 or 1). However I imagine there is a way to do it with just one command, so I suggest you try to find out how to do that rather than using the hack I suggested (this is why I put it in a comment rather than a new answer). – forest May 19 '18 at 00:24
  • @forest, When you say `sign and encrypt together` + `verify` + `decrypt`, `verify` would throw this error `gpg: verify signatures failed: Unexpected error`. So if I have to go with the `verify` + `decrypt` option, I need to break `encrypt` and `sign` into two steps. I will try to see if there is a single command. `gpg ` is a magic command which exits with an error code if either signature verification or decryption failed. But I am not sure If I can rely on that. Thanks for helping me. – Nishant May 19 '18 at 04:52
  • 1
    I still don't understand why you want to split the encryption and signature generation. If the recipient wants to decrypt a file with an invalid signature or no signature, they will always be able to, no matter how you package the signature. If you want to mandate signature verification, you need to act on the decoding procedure, not on the encoding procedure. – Gilles 'SO- stop being evil' May 19 '18 at 09:16
  • Right, @Gilles. My goal is to *abort* the decryption if signature check fails. Since `gnupg` only *warns* about it, I believe the correct way is to do `gnupg -es file` at the senders end and `gnupg --status-fd -d encrypted_file | verify` at the receivers end where `verify` is just a simple custom script that checks the status and aborts the process if needed. There seems to be nothing internal which does that and I think that is sensible in some ways. – Nishant May 19 '18 at 09:26

1 Answers1

1

You're trying to use technology to solve a people problem

This is generally not a good idea.

Let me explain a bit more in-depth. You - the sender - generate a message, then encrypt it and then sign the encrypted message. This is akin to writing a letter, putting it into a box, locking the box and then putting your signature on the box.

You want the recipient of the message to verify your signature, then decrypt it and read your message. This is akin to them looking for the signature, verifying that it is correct, then unlocking the box and then reading the letter.

The problem in both scenarios is that you can't control how the other person is going to act. They could be lazy and always just unlock any box they find, just how they could just decrypt anything they find without checking who sent it.

A people problem...

Before, I stated that this is a "people problem". What I mean by that is that you want recipients to verify the signature, so that they don't trust something they're not supposed to. Some people just don't care, and it's hard to fix that. "Making someone care" is very difficult, and human psychology isn't really helping.

For example, when a user does something, they do that for a specific reason. If a computer asks them "Do you really want to do that?" then, they will just click whatever button they need to click for that message to go away. This is true for many security warnings, and unfortunately, there's not a lot you can do technology-wise.

...requires a people solution.

But what you can do is educate users. Explain to them what a signature is, why it's important and why they should care. And if your reason for them to care is because it's mandatory, as you said, then that should be a good enough reason.

Imagine your boss would come in today and say "Look, if there is a warning and you ignore it, you could get fired", then I have quite a high incentive to not click that warning away. It's a people solution, even if it's negative reinforcement.

Security at the cost of usability comes at the cost of security

Someone who is much smarter than me, but who's name I don't remember, once said that. And for all intents and purposes, it's true. You want to use signatures to improve security, and that should be hassle-free for your users. Signatures should be verified automatically without users even having to think about it.

If you tell a user "Command foo does the thing you need to do. Command bar needs to be run before foo and it does something you don't care about", guess how many users will actually run bar and then foo? Approximately none.

Instead, deploy a script that automatically runs bar, checks if the signature is valid and then runs foo.

Community
  • 1