0
$\begingroup$

Is there any downside to encrypting the original message for signing purposes. I understand this does not provide actual protection, and any one with the public key (any one in the world if the public key is made completely public), however, it would seem if the public keys were kept restricted to TLS tunnels and required password access, this would seem to be a small layer of protection. The upside is small, but is there any downside?

$\endgroup$
1
$\begingroup$

There are actually a few downsides which mostly depend on the size of the original message.

So recall that for signing purposes, the hash (or message digest) is used to sign the document. Thus assuming that the message is large we can face several possible issues:

1. Efficiency: Recall that signature schemes use asymmetric encryption which is much slower than symmetric encryption. So if you were to sign the entire message it could take some time. (Hash or message digest is relatively small in size and thus fast to sign)

2. Integrity: Given the message is too large (for the signature space) the message may be required to be split into separate blocks (separate messages). Now each message created must now be signed differently and the order of the message blocks may need to be preserved which is an additional overhead.

3. Compatibility: Some signature schemes such as RSA can not operate on Bit strings so it adds extra difficulty re-configuring the message or changing the signature scheme.

Of course, if the message is small, it can get away with the first two issues with small overheads, but it's probably better to use a key-sharing encryption scheme with signatures rather than have to go through all this overhead.

Let me know if that raises any other questions, Cheers!

$\endgroup$
2
  • $\begingroup$ I've upvoted, but note that for (1) you'd probably require a hybrid cryptosystem anyway, (2) as the message was signed, integrity of the plaintext may not be an issue (3) signature schemes do operate on bit strings (and they even output a bit string or rather octet string, as the use of I2OSP is standardized). $\endgroup$
    – Maarten Bodewes
    Apr 6 '18 at 12:06
  • $\begingroup$ The question assumes that the standard method of hashing the data and then signing it is used instead of signing the entire raw message. I'm just interested in the supposed value of the 'scrambled' text you get when using the private key to encrypt. I don't even know if it is fair to say this is encryption. I am assuming if you encrypt with the private key, you need the public key to get it back. $\endgroup$ Apr 10 '18 at 17:11
1
$\begingroup$

It is not possible to directly encrypt with the private key as the signature value is exactly the size of the private key. So a message + signature it will be too large for the private key to encrypt. It would therefore be required to use a hybrid cryptosystem (e.g. AES + RSA) to encrypt in the first place.

It is normally required to encrypt the signature, otherwise an adversary may try and reconstruct the message and verify it against the known signature.

Generally encryption is not performed with private keys:

  • the operation of doing so may simply not be available (e.g. if the key is stored in hardware, or if a library has a higher level API);
  • the operation may fail if the private key (only) contains the CRT parameters (and not the private exponent);
  • the operation may fail if the implementation requires a small or even specific public exponent;
  • the operation may choose the wrong padding mechanism for signing;
  • the operation may not be protected against side channel attacks that could be used to find the private key.

If you need to keep the public key secret then you might as well use symmetric encryption: distribute a symmetric key and perform authenticated encryption for the recipients. You can still sign the plaintext message if that's required.

You could of course encrypt a symmetric key using the public key and decrypt that at the side that wants to encrypt the message. Then that could be used to perform the authenticated encryption. It's would still use the public key but it avoids many drawbacks listed above.

Using TLS could also be an option, although you'd still have to control who is allowed inside, of course.

$\endgroup$
1
  • $\begingroup$ These are some of the technicalities. You may also make it abundantly clear to a person receiving the specification that you are a greenhorn. Anybody that starts with crypto probably thinks it is a great idea at some time or another. Until somebody steps in and squashes the idea. $\endgroup$
    – Maarten Bodewes
    Apr 6 '18 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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