只能由一个特定人员验证的数字签名

#1 楼

您似乎要寻找的是可拒绝的身份验证。

这实际上是一个比您要的要强的属性：它可以确保接收者（我们称他为Bob）无法通过密码说服其他任何人即使发件人公开了所有私钥，发件人（让我们称其为爱丽丝）也已对该消息进行了签名，这仅是因为该协议保证了知道鲍勃（和/或爱丽丝）的私钥既是验证签名所必需的，也是伪造该签名所必需的。因此，鲍勃（Bob）看到一条带有有效签名的消息，并且知道自己没有创建该消息，因此可以确信爱丽丝一定已经发送了该消息-但他不能使用签名说服其他人，因为他本可以


实现两方之间这种经过身份验证但可抵赖的通信的最简单方法是使用对称密钥经过身份验证的加密方案（或者，如果消息保密，出于某种原因而不是必需的，只是一个普通的MAC）。通过这些方案，Alice和Bob知道了用于验证消息和验证其真实性的相同密钥。因此，琐碎地，Alice可以做的任何事情（例如创建一个声称是从Alice到Bob的有效身份验证消息），Bob或其他知道密钥的人也可以做。

这种对称密钥方案的主要缺点是，它们需要为每对通信方提供单独的密钥（如果可能有很多这样的方，这将变得很麻烦），并且必须以某种方式在每对方之间安全共享密钥。如果我们在每对双方之间都有一个经过加密和认证的安全通道，这将很容易，但是由于这正是我们要在此处设置的通道，因此会产生一种鸡与蛋的问题。


解决这些问题的一种方法是使用公共密钥加密来共享秘密密钥。特别是，我们可以使用Diffie-Hellman密钥交换在任何两个当事方之间建立共享的秘密，只要他们知道彼此的公钥（当然还有他们自己的对应私钥）即可。

Diffie-Hellman密钥交换通常被说明为交互式协议，但实际上，唯一需要的交互是各方将其公钥发送给另一方（他们可以事先这样做，例如，通过将它们发布到某个半-受信任的中央密钥服务器）。此后，只要任何一方（例如，再次是爱丽丝）想要向另一方（例如，鲍勃）发送消息，她都可以将其私钥与鲍勃的公钥结合起来，以获得只有她和鲍勃知道的秘密值，然后使用此机密（可能是在将其通过适当的KDF馈入后）用作上述经过身份验证的加密方案的对称机密。无论如何，对于实际使用，您不必实际上，您不需要自己实现任何一种，因为此类方案已有很多实现。例如，NaCl库（及其各种派生工具，例如libsodium）提供了crypto_secretbox函数（用于对称密钥身份验证加密）和crypto_box函数（用于可否认身份验证的公共密钥加密）。如果您不需要特别使用自己的加密方案，建议您使用那些加密方案或其他类似的经过充分研究的实施方案。

（您可能要这样做的一个可能原因是防止随机数滥用。上述NaCl函数要求您为每个消息分配一个唯一的随机数，如果您对两个不同的消息重复使用相同的随机数，则会严重损害其安全性。使用相同的密钥进行加密有一些基于SIV构造的经过身份验证的加密方案，可以更有效地抵抗这种随机数滥用，例如AES-SIV，AES-GCM-SIV甚至是HS1-SIV，但NaCl crypto_box目前不如果需要，可以使用crypto_box重新实现crypto_scalarmult的“哈希Diffie-Hellman”部分，并使用具有SIV风格的对称加密方案的结果密钥，但是与仅使用crypto_box相比，这需要更多的精力和精力。是。）


PS。稍微切线，请注意，仅Diffie-Hellman并不能完全解决密钥分配问题，因为它仍然依赖于各方能够共享其公共密钥而不会有人对其进行篡改。尤其是，如果Alice和Bob试图通过中间人Mallory控制的通道交换公钥，则他只需用自己的公钥替换Alice和Bob的公钥，然后拦截使用这些密钥加密的任何消息，然后解密并重新-在传递每条消息之前先对其进行加密。

（当然，如果Mallory停止这样做，那么Alice和Bob会发现自己无法通信，直到他们重新交换公用密钥为止。和鲍勃（Bob），看起来好像有人刚开始通过拦截消息并用无效伪造代替它们来攻击他们的通信。没有其他替代通信渠道，爱丽丝（Alice）或鲍勃（Bob）无法知道攻击是刚刚开始还是停止了。即使他们以某种方式解决了问题，也可能为时已晚。）

解决此问题的一种方法是建立某种公钥基础结构，第三方可以在此基础上对Alice和Bob的公钥进行签名，以保证其正确性。但是，设置可靠的PKI绝非易事，因为在某些时候您仍然需要信任某人。

#2 楼

可以说爱丽丝（Alice）想向鲍勃（Bob）发送敏感消息，她想向鲍勃（Bob）证明它是她发来的，但是她不希望鲍勃（Bob）能够向其他任何人证明这一点。

MAC是这样做的好方法。如果Alice和Bob共享一个MAC密钥（只有他们拥有），那么Bob将会知道任何使用该MAC密钥进行身份验证的消息都来自Alice，因为他知道自己没有做到这一点，而且她是唯一可以拥有的人。

但是，由于Bob与Alice一样具有创建MAC的能力，因此第三方无法分辨来自Alice的消息与来自Bob的伪造之间的区别。 />
环签名也可以使用，并且不需要他们共享秘密。在这里，爱丽丝将进行签名，以证明该消息来自爱丽丝或鲍勃。鲍勃知道他没有签名，但是他很难说服第三方。

#3 楼

验证签名的人有动机不公开密钥。


我看不出公开密钥的任何方法。除了拥有秘密之外，还有什么可以使指定的“验证者”与其他人区分开？

我相信我们可以使用公共/私有密钥对，这样只有“验证者”拥有

我们不能简单地让发件人对其消息进行哈希处理并使用众所周知的公钥对其进行加密以生成签名。这将允许任何人验证签名，因为任何人都可以对消息进行哈希处理并使用公钥对结果进行加密。尽管攻击者没有私钥，但这种“生成和比较”是一个制止者。 （实际上，私钥根本没有任何实际价值。）

幸运的是，我们应该能够通过引入不确定性（以随机的“ nonce”形式）来解决“可逆性”问题。数字。

当某人想要签名消息时，他们首先将输入消息与随机随机数配对，然后使用公钥对这对加密。生成的加密Blob可用作签名。 （不幸的是，签名的长度将大致等于原始消息的长度。）

“验证程序”可以轻松地验证完整性：他们使用私钥解密加密的blob，丢弃随机数分量，并将其他（消息）组件与未加密的消息进行比较。

没有其他人可以使用加密的blob，但是，由于没有私钥，他们无法解密它，并且由于使用他们无法使用随机数的生成和比较方法；它们的随机随机数将不同，这意味着它们将生成完全不同的加密blob。

（比我更有知识的人可能会知道这种方法是否有名称，或者可能是我错过的致命缺陷。）