非对称加密签名

Question

设(K_{enc},K_{dec})是非对称密钥对.在我看来，可以通过让公开验证密钥为K_{ver}=K_{dec} (非对称解密密钥)和秘密签名密钥为K_{sign}=K_{enc} (非对称加密密钥)来创建签名方案。使用H的一些散列函数和要签名的m：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. 在words中，一个通过加密(一个散列)来签名，任何人都可以通过解密(和散列)来验证。

N.B.密钥的公共/私有角色在应用程序之间被逆转！ K_{sign}=K_{enc} is保持私有(忘记它将作为加密密钥公开)和 K_{ver}=K_{dec} <#>is公开(忘记它作为解密密钥是私有的)。

如果是这样的话，为什么要开发单独的签名方案而不是重复使用公钥方案呢？不重新使用库尔德工人党似乎是一种浪费。专用签名方案效率高得多吗？

如果不是这样的话，又有什么问题呢？

当K_{dec}显示有关K_{enc}的信息时，注释中会出现一个问题。这肯定发生在某些(大多数)方案中，例如加密密钥实际上是解密密钥的一些模糊版本，但不是全部。防止这种情况或多或少是设计一个签名方案(“公钥解密”)，使我的问题变得无趣。

出现在脑海中的唯一具体实例是RSA签名，其中加密/解密指数之间的对称性使上述操作成为可能。

Answer 1

在我看来，可以通过让公开验证密钥为sk而秘密签名密钥为pk来创建签名方案，如果不是这样，有什么问题吗？

其想法似乎是“我们将采用基本的‘用密钥1加密，然后用密钥2解密’的公钥加密模式，将密钥1称为私钥，密钥2为公钥，并且我们拥有一个签名系统。”

然而，如果我们从一个安全的公钥加密系统开始，这可能不会产生一个安全的签名方案。

fgrieu已经从反对开始，这是最常见的公开密钥加密方案；对密钥2(在签名方案中成为公钥)的知识可能允许您推断密钥1。几乎任何基于离散日志或基于ECC的方案都属于这一类。

这可能会失败的其他方式：

• 我们可以推断出密钥1.许多基于格的签名方案正是因为这个原因而失败；结果发现，每个签名都泄漏了一些私钥--显然，这已经用当前基于格的签名方案(如Falcon和Dili三国)解决了。
• 也许，通过对明文的了解，“密文”是可以延展性的。也就是说，我们可以修改密文以解密成不同的明文。ClassicMcEliece (NIST第3轮决赛)属于这一类别。

底线:安全公钥加密系统的特性不足以产生一个安全的签名方案；如果有人提出这样的签名方案，就需要仔细审查(就像其他方案一样)。