【问题标题】:Confused about encryption with public and private keys (which to use for encryption)对使用公钥和私钥(用于加密)的加密感到困惑
【发布时间】:2011-02-27 20:29:46
【问题描述】:

当客户向我的服务器索取许可证时,我正在制作一个许可系统,如果允许他们拥有许可证,我会向他们发送许可证。

在我当前的系统上,我使用单个私钥加密许可证,并将公钥嵌入到他们用来解密许可证的客户端应用程序中。有效!

其他人告诉我,我应该使用服务器上的公钥加密并将私钥分发给客户端。我在网上搜索过,可以看到他们有时使用私钥加密,有时使用公钥加密。

在这种情况下,我该怎么办?

【问题讨论】:

    标签: java encryption drm private-key public-key-encryption


    【解决方案1】:

    其他人告诉我,我应该 用公钥加密 服务器和分发私有 客户的关键。

    那些人错了。 私钥这个名字暗示它是私有的,意味着只有你才能访问它。

    在这种情况下,我该怎么办?

    使用数字签名。使用您的私钥签署许可证文件,并在您的应用程序中使用您的公钥来验证许可证上的签名是否来自您。

    【讨论】:

    • 这是错误的。对于非对称加密,您使用收件人的公钥进行加密。
    • @Matthew 我没有另外说。我说他应该分发他的私钥。
    • 那么在我的情况下我应该怎么做?假设我将为所有客户端使用相同的公钥和私钥。
    • Kevin 是正确的,但我也注意到这正是 OP 一直在做的事情。 “用私钥加密” == 符号。而且由于这是一个 DRM 方案,根本没有真正的安全性,这是 Matthew 的最后一点。
    • @GregS:“用私钥加密”等于“符号”。在 RSA 中,每一种底层的基本操作都是一样的,但是使用的方法却完全不同。将签名视为“使用私钥加密”是获得不安全系统的好方法。
    【解决方案2】:

    如果您使用公私(非对称)加密,您始终使用收件人的公钥进行加密,收件人使用他们的私钥进行解密。对于数字签名,您使用您的私钥签名,而收件人使用他们的公钥验证签名。

    那么问题来了,你如何制作一个安全的 DRM 系统?如果您使用加密,并为收件人提供私钥,他们可以分发密钥或解密的内容。如果你使用签名,他们可以简单地去掉你程序的签名验证部分。

    答案是不可能的。 DRM 的概念存在根本缺陷。

    【讨论】:

      【解决方案3】:

      如果您要加密仅供单个收件人阅读的内容,那么您使用该收件人的公钥进行加密,他们使用他们的私钥来阅读它。

      如果您要为多个收件人加密,那么您可以使用您的私钥加密并将您的公钥分发给您希望能够读取它的人。这通常称为“签名”,因为任何有权访问您的公钥的人都可以读取它,因此这并不是一种真正的私人通信形式。

      对您而言,一个更强大的整体解决方案是让您的应用在每次安装时生成一个密钥对,将它生成的公钥发送回服务器,然后您将使用该公钥进行加密,以便只有单个安装可以使用您创建的许可证(通过使用其私钥解密)。

      【讨论】:

      • 签名不是加密,句号。即使没有您的公钥,人们也可以阅读该消息。他们只需要它来验证签名。您的“强大解决方案”中没有任何内容可以防止人们共享私钥。
      • 马修,你需要公钥来验证消息。
      • @Matthew- 我说“更健壮”,这是一个相对的断言,而不是绝对的断言。正如您在回答中指出的那样,如果有人想要绕过它,任何 DRM 都注定要失败,其想法是让普通人保持诚实,而不是完全安全。
      【解决方案4】:

      至少在典型的公钥加密算法(例如 RSA)中,公钥和私钥之间并没有太大的区别。生成密钥时,您将获得两个密钥。您将一个保密并发布另一个 - 但您发布哪一个以及您将哪个保密并不重要。

      你用一个密钥加密的任何东西都可以用另一个密钥解密。出于正常目的,您发布一个密钥,让任何人都可以加密只有您可以解密的内容。从技术的角度来看,相反的工作很好:如果你用你的私钥加密了一些东西,任何拥有公钥的人都可以解密它。这通常用于签名验证之类的事情(即,任何拥有公钥的人都可以验证必须使用私钥创建签名)。不过,您通常希望使用单独的密钥对进行加密和签名。

      就您的情况而言,您真正要完成什么是有待商榷的。您当然可以加密使用该程序所需的一些数据,因此用户需要密钥来解密它并使用该程序——但如果用户愿意将 代码 的副本提供给未经授权的人人,他们可能也会毫不犹豫地向他们提供密钥的副本。因此,即使加密/解密可以发挥作用,也不太可能提供任何真正的保护。

      更典型的许可方案与特定 IP 地址相关联,因此您可以执行诸如加密 IP 地址之类的操作,然后使用结果作为密钥来解密使用该程序所需的数据。如果 IP 地址错误,则无法正确解密数据,程序将无法运行。只要用户有一个静态 IP 地址,它就可以很好地工作——但会导致与 DHCP 结合使用的问题。

      我的直接建议是根本不要这样做。如果您仍然坚持这样做,请不要自己做——让FlexNet 之类的东西为您处理。没有它你会更好,但至少这样你会得到一些有点有效的东西,你不会浪费时间和精力在它可以用于更好的目的,比如改进你的软件。

      【讨论】:

      • 两年后我偶然发现了这一点,我想指出 Jerry 在这里是错误的 - 你保密哪个密钥确实很重要。给定 RSA 私钥,您可以计算公钥。永远不要泄露私钥。参照。 stackoverflow.com/questions/696472/…
      【解决方案5】:

      恭喜,您刚刚发明了 RSA 签名。 (无论如何,这是您应该使用的。)要与公钥系统进行通信,您需要使用一次私钥和一次公钥,但 RSA 支持两种不同的顺序: 1)用公钥加密,用私钥解密:接收者对消息的来源一无所知,但发送者知道只有接收者(私钥的持有者)才能阅读。这是经典的“加密”。 2)用私钥“加密”,然后用公众“解密”。这是一个数字签名,并提供身份验证。任何人都可以阅读该消息,但只有私钥持有者可以发送该消息。

      假设您的许可证是为客户端定制的(这可能就像包含客户端生成的随机数的副本一样简单),那么它对其他人毫无用处,但客户端可以确定是服务器发送了它。

      实际上,对称性并不是那么整齐;不同的操作模式有不同的弱点和陷阱,所以实现通常会有很大的不同,但这是一般的想法。

      密码学的第一课也是最重要的一课是了解身份验证以及何时使用它。它的需要至少与加密一样频繁,不知道何时使用它会让您陷入Midvale School for the Gifted 的境地。

      【讨论】:

        【解决方案6】:

        希望维基百科的这个链接有所帮助。 PKI 建立在相互信任的基础上。但是,私钥必须由所有者保护。顾名思义,公共对所有人开放。制作整个架构是为了帮助您解决上述问题中定义的场景。

        【讨论】:

          猜你喜欢
          • 2011-12-06
          • 1970-01-01
          • 1970-01-01
          • 2011-07-24
          • 1970-01-01
          • 1970-01-01
          • 2017-01-04
          • 1970-01-01
          • 2015-11-29
          相关资源
          最近更新 更多