【问题标题】:Is it safe to encrypt a string using same string as key?使用与密钥相同的字符串加密字符串是否安全?
【发布时间】:2011-04-07 23:40:41
【问题描述】:

在 CBC 模式下使用 AES 和使用 IV(当然)使用自身加密给定密钥是否存在任何安全缺陷?

遵守原则:密钥是秘密的,IV 是公开的(因为这不会影响加密的安全性)。

但是,潜在的攻击者会知道(因为他可以访问源代码),字符串是使用自身作为密钥进行加密的。

我的判断没有发现任何问题,但我正在努力确定。

谢谢。

编辑 - 任务的细节,我希望我能清楚地传递它们,这对我自己来说还不是很清楚:

  1. 我的系统使用加密将某些值存储在 MySQL 表中。加密是在 PHP 代码上执行的(不是 MySQL 内置的 AES)。显然,我需要一个密钥,它需要由系统管理员在系统设置时设置一次。这一点很关键,因为在保存任何加密数据后更改密钥会使该数据无法解密。

  2. 管理员可以通过简单地通过 FTP(或其他)编辑 PHP 脚本文件来设置密钥。但这不是我想要的。

  3. 我想要的是有一个安装脚本,在此期间管理员会选择密钥,该密钥会自行加密并存储到表中。当然,下面提出的一个有效观点是,您需要密钥来解密密钥......我的推理没有深入,我正处于调查是否用自己加密密钥的阶段因为密钥仍然是安全的东西。

如果您对上述内容有任何想法,我们将不胜感激。

谢谢。

【问题讨论】:

  • 起初我同意@Piskor,“有什么意义?”但是我看到,如果您自己加密了密码,然后存储了生成的密文,您可以通过尝试使用提供的密码解密密文来验证正确的密码。这与您的用例相似吗?
  • 只是我还是你的标题和问题不同? :S
  • @Greg 如果他只是测试密码是否正确,他最好存储密码的加密哈希。您对用户的输入进行哈希处理,如果哈希匹配,您就知道输入的密码是正确的。
  • @Greg:我希望它就这么简单,对于简单的密码检查,我只需使用 SHA 哈希并完成它。 @Ranhiru Cooray:我想只有你 :)

标签: encryption


【解决方案1】:

问题是,重点是什么?如果要解密字符串,必须已经知道字符串;如果你不知道它,你应该无法解密它。恕我直言,这是可能的,但毫无意义。

【讨论】:

  • 它提供给您的唯一功能是能够确认给定字符串实际上是密码。 (您自己加密它并查看字符串是否匹配,或者您解密存储的字符串并查看字符串是否匹配。)有已知安全的方法来获得此功能 - 为什么要冒险创建一个可能有细微弱点的方法。
【解决方案2】:

用自己加密密钥基本上是一个 ad-hoc 散列函数。所以你可以用一个真正的来代替。

【讨论】:

    【解决方案3】:

    正如您在 Jesper 的回答中的评论中提到的那样,“强度存在于加密密钥中”和加密算法中。如果两者都很强,它应该是安全的。据我所知,强加密和密钥的技术薄弱环节在实施中,如果有的话。

    有兴趣知道你打算将此方法用于什么应用程序,如果你能说出来的话。

    编辑这并不能完全回答帖子标题中的问题,但我认为它与您更新的帖子有关:

    假设具有 CBC 和 IV 的强大且正确实施的 AES,并且攻击者可以访问您存储加密主密钥的表。

    无论您是使用自身存储加密的主密钥,还是存储主密钥的加密哈希值,安全性差异应该很小。假设 CBC 模式下的加密哈希和 AES 都同样安全,那么优势在于主密钥的强度。

    如果主密钥很弱,即使攻击者无法从主密钥的加密哈希中获取主密钥,他也可以通过“某些值”获取主密钥,从而获得“某些值” “ 桌子。如果使用主密钥加密自己,他可以通过“某些值”表或主密钥表获得主密钥。

    无论您选择使用相同的密码来加密和存储主密钥还是以加密方式散列并存储主密钥,请确保主密钥是强密钥。好像您正在编写一些开源系统。我的建议是,您的系统会根据正则表达式(或函数)检查任何潜在的主密钥,如果认为它不够强大,则拒绝该密钥。

    希望我也正确理解了您的帖子。

    免责声明:我不是安全专家,也不从事安全行业。

    【讨论】:

      【解决方案4】:

      第一:不是真正的安全专家

      所以目前要获取这个,你想存储一个秘密值,并且只能获取秘密值,但告诉它秘密值? :)

      但是我可以看到你想用这个去哪里,对于密码系统(也许),你可以一起验证它们。

      一些缺点可能是,如果黑客可以访问所有用户的密码,并且黑客有一个他能记住的密码的帐户,那么他可以很容易地发现你的加密逻辑。他可以在那之后,只需进行字典攻击,并获得大量密码。为此,我至少会考虑为每条记录使用唯一的哈希。然后他仍然可以字典攻击,但需要更长的时间。然后还要添加一个存储在您的应用程序深处的自定义哈希,因此他也需要猜测,或者有权访问应用程序代码。

      所以我至少会推荐一个由密码+record_hash+shared_hash 组合而成的密钥

      更新:我可以看到黑客可以访问代码,然后尝试将 shared_hash 存储在他无法访问的地方。

      【讨论】:

      • 黑客将有权访问加密逻辑,无论如何,他将能够看到(开放)源代码。因此,像往常一样,强度在于加密密钥。
      • 我可以在您的更新中看到,在您的情况下,它确实是一个一键式场景,那么我看不出您的解决方案有问题。 :)
      猜你喜欢
      • 1970-01-01
      • 2017-01-17
      • 1970-01-01
      • 2022-06-14
      • 1970-01-01
      • 2010-11-22
      • 2023-04-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多