服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

GPG / PGP签名和encryption – 学术安全问题

数字签名 数字签名发生在您将私钥应用于特定的邮件(或大多数情况下,该邮件的哈希值)。 然后收件人将您的公钥 (公开可用)毫不奇怪,然后通过将其应用于签名的邮件来validation您的身份。 encryption 另一方面的encryption发生,你把你的信息是谁的人的公钥 ,并将其应用于消息。 一旦你完成了这个任务,你实际上已经locking了每个人(包括你自己),解锁这个消息的唯一方法就是让接收者把他们的私钥应用到encryption的消息中。 “应用” 在上面的两个场景中,我使用了“apply”这个术语,那是因为这是我的最后一个问题。 数字encryption和签名基本上是一个非常大的数字(公钥/私钥)在math上适合于消息的math乘法。 当私钥被公钥“相乘”时,它们相互抵消(有些简化的描述)。 我已经在这里用Diffie-Helman写了一个简单的例子。 问题/安全问题 现在考虑到这一点,我正在考虑这个场景。 想象一下,你使用标准的不对称密码(pri / pub keys)来窃取秘密信息,并对其进行encryption。 然后,您通过不安全的渠道将该消息发送给收件人。 窃听者点击线路并捕获您的消息。 然而,对他们的消息是encryption的 – 他们猜测消息的真正接收者(拥有相应私钥的人)使用相同的公钥/私钥对进行签名,就像encryption一样。 他们以某种方式操纵/说服消息的真正收件人签署“一些文件”,并且假设她是这样做的。 文档当然是被捕获的消息,但收件人不知道这一点。 刚刚发生了什么? 收件人已将她的私钥应用于已由其公钥签名的邮件。 然后,她会把这个消息交给行凶者(让我们假设这是一个盲目的请求)。 攻击者现在有解密的消息? 澄清问题 谢谢大家的回应 – 似乎我没有把我的问题说出来,因为每个人都误解了 – 这是我的错,所以很抱歉。 澄清 :假设对整个消息执行“签名”操作(这里是学术目的),而不是该消息的散列。 是的,我知道这不是实际完成的,而且由于原因(包括性能和大小),签名是在消息的固定长度encryption哈希上完成的,而不是消息本身,但是对于这个问题,请假装这个事实并非如此。