Signatures from asymmetric encryption

Let $$(K_{enc},K_{dec})$$ be an asymmetric key-pair. It seems to me that a signature scheme can be created by letting the public verification key be $$K_{ver}=K_{dec}$$ (the asymmetric decryption key) and the secret signing key be $$K_{sign}=K_{enc}$$ (the asymmetric encryption key). Say with $$H$$ some hash function and $$m$$ to be signed: $$s=\texttt{sign}(m,K_{sign})=\texttt{encrypt}(H(m),K_{enc})$$ $$\texttt{verify}(s,m,K_{ver})=\left\{ \begin{array}{cc} \text{True }&\text{if } H(m)=\texttt{decrypt}(s,K_{dec})\\ \text{False }&\text{else}. \end{array} \right.$$ In words, one signs by encrypting (a hash of) the document and anyone can verify by decrypting (and hashing).

N.B. The public/private roles of the keys are being reversed between applications! $$K_{sign}=K_{enc}$$ is kept private (forget that it would be public as an encryption key) and $$K_{ver}=K_{dec}$$ is made public (forget that it would be private as a decryption key).

If this is the case, why develop separate signature schemes instead of reusing public-key schemes? It seems a waste not to repurpose the PKC. Are dedicated signature schemes that much more efficient?

If this is not the case, what goes wrong?

One problem noted in the comments occurs when $$K_{dec}$$ reveals information about $$K_{enc}$$. This definitely occurs in some (most) schemes, say when the encryption key is really some obfuscated version of the decryption key, but not all. Preventing this is more-or-less designing a signature scheme ("public-key decryption"), making my question uninteresting.

The only concrete instance that comes to mind is an RSA signature, where the symmetry between the encryption/decryption exponents makes the above possible.

• In EC crypto, the public key $K_{enc}$ can be trivially derived from the private key $K_{dec}$. Therefore, if you give out $K_{dec}$ to the public, the public can determine your $K_{enc}$ and your "signature" would be forgeable. Mar 26 at 14:28
• If we're misunderstanding something, it might helpful if you took some public key encryption algorithm (other than RSA), and write out exactly what you propose... Mar 26 at 20:42
• I suggest to change the question's title to “Signature from asymmetric encryption”, because (digital) signature is considered part of asymmetric cryptography.
– fgrieu
Mar 28 at 5:48

The good

The method in the question leads to a signature system that always successfully verifies the message it signs; and there are combinations of asymmetric encryptions schemes and hashes where that signature system meets the EUF-CMA security property, including:

• RSAES-OAEP close to as practiced, and a standard cryptographic hash like SHA-256. Two tweaks are needed to the RSA part, though:
• Choosing $$e$$ random and of large bit size (half the bit size of $$n$$ seems OK) rather than $$e=65537$$ as common (or other lower guessable value, or random but too low for security¹ of the question's method)

• Expressing the decryption key $$K_{dec}$$ as $$(n,d)$$ rather than as the usual $$(n,e,d,p,q,d_p,d_q,q_\text{Inv})$$, used by standard implementations that care for performance.

Both changes are necessary to keep $$e$$ of $$K_{enc}=(n,e)$$ secret when we make $$K_{dec}=(n,d)$$ public, as in the question.

• RSA encryption as in the original article except with $$n$$ large enough to resist modern factorization methods², and a hash considerably larger than above in order to resist the Desmedt and Odlyzko attack.

The method is unsafe when applied to most asymmetric cryptosystems

Observe that $$K_{dec}$$ must be made public since it's the verification key, and $$K_{enc}$$ must be kept secret since it is the signing key. Thus the relation between the two keys must be such that we can make $$K_{dec}$$ public while preserving the secrecy of $$K_{enc}$$. RSA is the only family of encryption schemes I know well that can have that property (and as explained above, it's practical implementations do not).

For many asymmetric encryption systems, the property can't be made to apply. For example, in ElGamal and it's modern descendant ECIES, $$K_{dec}$$ is an integer that encodes how to reach group element $$K_{enc}$$ by applying the internal group law to a certain public group element; therefore revealing $$K_{dec}$$ unavoidably reveals $$K_{enc}$$, breaking the security of the question's construction.

More generally, using a secure asymmetric encryption system and a secure hash is no good indication that the signature system obtained by the question's method is secure, for a variety of reasons.

When we consider implementation security, there's a further issue: an implementation of $$\texttt{encrypt}$$ needs no protection against side channel leakage of it's key input, since it's normally public. However such protection is required for the question's signature system.

The method tends to build signature schemes with substandard characteristics

Comparing RSA signature (including by the question's method) to EdDSA at standard security level:

• The signature is rather large (256 bytes compared to 64 bytes)
• The public key is large (typicaly 260 bytes compared to 32 bytes)
• Signature generation is slow (like dozens times slower)
• Key generation is painfully slow (like hundreds times slower).

And the method is not quite what's used to build RSA signature, even the close cousin RSA-FDH. That uses the textbook RSA private-key function $$h\mapsto s=h^d$$ to sign a wide hash $$h=H(M)$$; and the textbook RSA public-key function $$s\mapsto h=s^e\bmod n$$ followed by a comparison $$h\overset?=H(M)$$ in verification. Contrary to the question's method, the public key $$(n,e)$$ remains public, and the private key $$(n,e,d,p,q,d_p,d_q,q_\text{Inv})$$ remains secret. Compared to that, or RSASSA-PKCS1-v1_5 or RSASSA-PSS, the question's signature method:

• Signs nearly four times slower, because it can't use the $$(n,e,d,p,q,d_p,d_q,q_\text{Inv})$$ form for $$K_{dec}$$
• Verifies like a hundred to a thousand times slower, because it can't use a small $$e$$.

¹ With $$n$$ known, if one of $$e$$ or $$d$$ is known and less that $$n^{0.292}$$, then the other can be found, see Boneh and Durfee. Therefore the customary limit of 256-bit $$e$$ (e.g. built into the key generation method of FIPS 186-4) is such that revealing $$d$$ allows to find $$e$$.

² The original recommendation “that $$d$$ should be chosen from a large enough set so that a cryptanalyst cannot find it by direct search” then compute $$e$$ from $$d$$ was inadequate, and allowed Wiener's attack, later improved by Boneh and Durfee. But keeping $$d$$ secret and making $$e$$ public as the question's method requires fixes that issue.

• I apologize if I've been unclear, but I believe you're misunderstanding my question in the same way as @poncho. I'm not trying to randomly shove encryption/decryption keys into the wrong holes.
– yoyo
Mar 26 at 17:57
• @yoyo: in the new wording, I agree you do not "randomly shove encryption/decryption keys into the wrong holes". I revised my answer.
– fgrieu
Mar 26 at 18:49

It seems to me that a signature scheme can be created by letting the public verification key be $$sk$$ and the secret signing key be $$pk$$

If this is not the case, what goes wrong?

The idea appears to be "we'll take the fundamental 'encrypt with key 1, and then decrypt with key 2' paradigm of public key encryption, call key 1 the private key, key 2 the public key, and poof we have a signature system".

However, if we start with a secure public key encryption system, this might not yield a secure signature scheme.

fgrieu already started with the objection that is the most common to fielded public key encryption schemes; knowledge of key 2 (which in the signature scheme, becomes the public key) may allow you to deduce key 1. Just about any discrete-log or ECC-based scheme falls in this category.

Other ways this can fail:

• It may be that given a long series of messages and signatures, we can deduce key 1. A number of lattice-based signature schemes failed for exactly this reason; it turned out that each signature leaked a bit of the private key - obviously, that has been addressed with the current lattice-based signature schemes (such as Falcon and Dilithium).

• It may be that, with knowledge of the plaintext, the 'ciphertext' is malleable. That is, we can modify the ciphertext to decrypt to a different plaintext. ClassicMcEliece (NIST round 3 finalist) falls in this category.

Bottom line: the properties of a secure public key encryption system are insufficient to yield a secure signature scheme; if someone does propose such a signature scheme, it needs to be carefully vetted (just like any other scheme)

• I'm not suggesting one "encrypt with the private key." I'm saying "encrypt with the PKC public key" is signing, and "decrypt with the PKC private key" is verifying. (The public/private roles of the keys are being switched between the PKC and the signature scheme.)
– yoyo
Mar 26 at 0:24
• @yoyo: so, anyone with the public key can sign, but only someone with the private key can verify"? That doesn't conform to the standard meaning of signing... Mar 26 at 1:43
• @poncho forget public/private (the roles are being reversed between applications). I've rephrased the question some to avoid confusion.
– yoyo
Mar 26 at 13:49
• @yoyo: it sounds like my answer is appropriate, then - with most current public key encryption schemes, it doesn't make sense to 'encrypt' with the private key (the one you keep secret) and 'decrypt' with the public key (the one you publish). Mar 26 at 16:01