7

-edit- After following a chain of links from this question I see this is similar/duplicate of Why should one not use the same asymmetric key for encryption as they do for signing? but this question is asking if there is a technical reason why we shouldn't and the linked is less technical and not exclusively to rsa

I may have the wrong understanding. GPG lets you generate a RSA key that is sign only. From my understanding an RSA key is a public and key pair. Signature works by hashing the message and encrypting it with the private key and others decrypts it using the public key. From my understanding if the hash matches what is decrypted than the message is signed.

How can GPG generate a key and sign it but not let me encrypt messages? I believe in another app it suggested you have one key for signing and one key for encryption but there was no reason why. Wouldn't that be confusing because an encrypted message and a signed cleartext would be using different keys and appear to be from a different user?

Community
  • 1
  • 1
    You encrypt with the target's public key, they decrypt with their private key. Signing is a separate mechanism. It involves signing with your private, and verifying with your public key. You can designate keys as "Signature Keys" or "Encryption Keys". You're right in that normally you can perform both actions with the same key-pair. However, the GPG client will see these flags and only allow one or the other. This is an attribute of GPG, not RSA itself. – RoraΖ Jul 07 '15 at 18:22
  • @raz: I'm not satisfied with Thomas answer (although it doesn't mean its bad). Do you know why GPG separates the two? (I'm unsure but it looks like your comment is assuring me that everything I said is correct or mostly correct and assuring me its something GPG does for their reason which I do not know) –  Jul 07 '15 at 20:30
  • In encryption, you use either a symetric key for encryption and decryption, or a public-private keypair. How do you want to transfer a secret key to someone who wants to send you an encrypted message? – ott-- Jul 07 '15 at 21:37
  • @ott--: Your question is flawed. I don't want to transfer a secret (or private) key to anyone. I want to give them a public key. –  Jul 08 '15 at 00:04

2 Answers2

7

Please don't use the "explanation" of signatures as "encryption with the private key" because it is a flawed analogy that does not actually work.

RSA is really two algorithms, one for asymmetric encryption, and one for signatures. It so happens that the two algorithms have some common mathematical elements, and, in particular, use the same kind of key (which is why we call it a "RSA key", not a "RSA encryption key" or "RSA signature key"). Thus, it is conceivable that a given RSA key pair may be used for both encryption and signatures.

However, there are good reasons why you would like to keep encryption and signature keys separate. The OpenPGP format acknowledges that, and thus "tags" keys with an indication of their intended usage. Therefore, your signature-only RSA key is a RSA key that OpenPGP tagged with a label that mostly says "please don't use that key for encryption".

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1) Why is the analogy fallowed and not work? AFAIK signatures are is a hash of the message and encrypted with the private key 2) I called it the same key hence why I am confused why we need two 3) That link made no sense. In short it doesn't explain why a key for signing not be backed up. It just says it doesn't need to bc it isnt a big deal and thats why it's separated from an encryption key. I don't see why anyone should bother separating it or why it's harmful to back up –  Jul 07 '15 at 19:32
  • 1
    @acidzombie24 As you´re saying yourself, the sign and encryption algos are *not* the same. First, signing contains hashing. Second, there is OAEP (nobody uses plain RSA because security). etc. ... and that the rest is similar to encryption is specific to RSA. I know no other public key system where this holds (I don´t think there is one). – deviantfan Jul 07 '15 at 20:47
  • @deviantfan I'm not sure what you're trying to say. My entire post is about the fact I can do signing and encryption with the same RSA key. I'm asking why GPG and others don't appear to recommend doing so –  Jul 07 '15 at 20:53
  • @acidzombie24 Signing never involves encryption. For RSA at a basic level signing involves DECRYPTING with private key. In reality it is more complex. You really need to get away from the incorrect and simplistic view that SIGNING is anything but SIGNING. SIGN, VERIFY, ENCRYPT, DECRYPT are four distinct cryptographic operations. There is some similarity between DECRYPT and SIGN in RSA but for other systems like ECC SIGN AND DECRYPT have nothing in common. – Gerald Davis Jul 07 '15 at 21:44
  • @GeraldDavis maybe I'm misunderstanding. When using RSA to encrypt it's something similar to encrypting an AES key and SHA of the message (along with some other data) then concatenate the (AES) encrypted message to it. Is signing just encrypting the SHA concatenate the plaintext and public key? Did you mean to say there are similarity between DECRYPT and **VERIFY**? I'm not sure what I am misunderstanding –  Jul 08 '15 at 01:11
  • @acidzombie24 VERIFY is similar to ENCRYPT (not decrypt). SIGN is similar to DECRYPT (not encrypt). You use the sender's private key to DECRYPT and SIGN. You use the receiver's public key to ENCRYPT and VERIFY. So my point was you really should do yourself a favor and treat SIGN, VERIFY, ENCRYPT, and DECRYPT as distinct operations because they are (as Thomas points out) BUT even if you want to follow that broken X is like Y explanation your explanation was wrong and is still wrong because you mixed up the relationship. As a SAT problem; SIGN is to DECRYPT as VERIFY is to ENCRYPT. – Gerald Davis Jul 08 '15 at 01:15
  • @GeraldDavis Hmmm that makes sense. I saw decrypt and verify to be similar because you're using the senders public key to decrypt the SHA. It's weird to hear signing is decrypting because you'd decrypt (sign) before encrypt (verify). But I see what you're saying (verify and encrypt both use the target public key –  Jul 08 '15 at 03:33
  • This answer indicates that the "sign only" is just a tag added to a key pair that tells gpg that it should not use the key for encryption. So does that mean that if I try to encrypt with a "sign only" key gpg will say that is not allowed? Thus technically you can use the key to both encrypt and sign but gpg allows you to enforce a separation because it is good practice? – Arthur Thompson Dec 02 '15 at 01:57
5

Why do apps encourage you to use separate key-pairs for encryption and for signing?

You are correct that there is no technical reason why you can't use one RSA key-pair for both encryption/decryption and signing/verification. But just because the technology will allow it, does not mean it's a good idea. The reason why has to do with backups and what happens if you lose your private key (or have it stolen). I think the best way to explain this is to walk through some example cases.

For the following, let's say that a 1-keypair user is someone who uses the same keypair for encryption and signing operations, while a 2-keypair user is someone who has two separate keypairs attached to their profile.

For these examples, let's also say that you have a bunch of important files on your hard drive that you've encrypted for yourself, and also a bunch of documents that you've signed and sent to other people.

Case #1: 1-keypair user, you lose / delete your private key

You can no longer decrypt the files on your hard drive. All those things that were important enough to encrypt? They're gone, you'll never get them back. This may sound silly, but people lose their keys all the time when they lose their phone / laptop dies / they forget the master password, etc. With GPG there's no way to recover it.

As for signatures, no problem, the documents you've already signed will still verify properly because the paired public key is still fine, and for new documents you can just make a new signing key.

You may think "Alright, then I'll backup my private key on dropbox or something", well consider Case #2

Case #2: 1-keypair user, your private key gets stolen by a hacker

When you put your data on cloud storage, you are allowing the admins of that server to access it. So some other person (who's not you) now has access to your private key - at least in theory. So what? Well, if they ever get your laptop, they can decrypt those important files. Also, and more importantly, they can now sign documents in your name.

This may not be a big deal for you, but since digital signatures are legally binding in some places, it's a huge deal for politicians and lawyers who don't want hackers singing legal contracts on their behalf. In law, there is a concept of non-repudiation which means that if a document bears your signature then we know that you were the person who signed it. As soon as more than one person has access to your private key (even in theory), you can no longer claim non-repudiation, which means, in the worst case, that any contract you've ever signed with that key becomes void.

These two cases show that:

  1. You want to back-up your decryption private key so that there's no risk of losing your data. In fact many companies and government organizations require their employees to back-up decryption keys on a central server.

  2. You never ever Ever EVER EVER want to back-up a signing key. Ever.

The Solution

For 1-keypair users you have to choose between protecting your data, and protecting your non-repudiation. Meanwhile,2-keypair users don't have that problem, and since there's really no downside to having a second keypair in your profile, there's no reason that anyone should ever be a 1-keypair user.

Community
  • 1
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 1
    This is a great answer. To me losing my encryption key is a bigger deal as losing my signing key (data loss). But now I see reasons why someone might care about signing. But all in all there is a copy of your key (on your laptop or where ever) and it could be as easily stolen. I don't see how multiple copies would be any different you never know which will be least secure. Even if they are stolen the passphrase should be strong enough to prevent people from signing. But you're saying for law only one copy should exist and only you should have access to it? A little strange but makes sense –  Jul 08 '15 at 00:47
  • 1
    @acidzombie24 For high security legal signatures, singing keys are often on chip cards (like your bank card) so that your computer can only sign things while the card is inserted. The private key is generated on the card and never leaves the card, making it very hard to steal. -- Though for your GPG-on-a-laptop case, none of this really matters :-P – Mike Ounsworth Jul 08 '15 at 01:23
  • AFAIK GPG automatically generates the signature keys and stores it on your HD. It has no prompts or suggestions (AFAIK) to store it externally. I'm unsure how to even use a key outside of the default location. I have only import/export and did various signs and encrypt to learn the software. –  Jul 08 '15 at 02:05
  • You can certainly export GPG keys to a *.asc file (called ASCII Armor) and then import them onto a different machine. I currently have 2 computers and 3 email apps all using the same GPG private key. – Mike Ounsworth Jul 08 '15 at 02:09
  • Well you said "The private key is generated on the card and never leaves the card" so importing would be out of the question as it stores a copy on your HD. Come to think about it. Isn't this all very ridiculous? If we wanted to have that level of security we could just have the RSA key only on the card. I see no reason why we can never encrypt with that key on the card (but then again I don't see a reason to encrypt) and I especially don't see a reason to have two keys for a casual users who might want to sign some source code, or text on his website. –  Jul 08 '15 at 03:30
  • Because you don't know just how casual that "casual user" is, and they might not know either! Perhaps they'll sign one random file, then another, then dozens of important ones. So now they have to stare at the key generation screen and worry, "will I need two keys or not?" What I'm trying to say is, your proposal doesn't make things easier for the user, it makes things *harder*. The keys are small. They take moments to generate. The *only* thing the user would gain from 1-key mode is a feeling of inferiority. – user1686 Jul 09 '15 at 09:33
  • 1
    In the past PGP used to label the key size suggestions "casual", "business", "military" grade, because there were noticeable speed gains from using a weaker key, and you were unlikely to be targeted by supercomputer-wielding TLAs. Nowadays it's the opposite, there is no reason to settle with weak cryptography anymore where strong crypto is available. – user1686 Jul 09 '15 at 09:39