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