共享密钥长度

Question

我正在尝试使用共享密钥创建经过身份验证的HTTP服务端点。

一个很好的例子是Flickr signing scheme。

我想知道什么是最佳公钥和密钥长度？我几乎肯定人们会说任意，但想知道一般意见是什么以及为什么。

另一个问题，Flickr使用MD5生成“签名”。我读到MD5不再安全，MD5的替代品是什么？而且，由于服务的消费者需要生成这个签名，奖励点易于使用和多平台库支持。

Answer 1

至于MD5的替代方案，我认为SHA family of hash functions被认为是事实上的替代品。它们有不同的散列大小：

• SHA1
• SHA256
• SHA512

显然，较新版本（具有较长的哈希值）将提供更高的安全性。有报告SHA1 is broken，但对于大多数实际应用，我仍然认为它是安全的。

当选择共享密钥长度时，我将寻找与散列值的长度大约相同的长度，以便具有足够的可能密钥空间。在我看来，选择更长的钥匙不会带来额外的好处。如果有人在哪里暴力攻击您的应用程序，理论上他们会在尝试尽可能多的密钥时找到密钥，因为有可能的哈希值。 （免责声明：我不是密码专家，可能在之前的陈述中出错了。）

今天，大多数平台都支持SHA，包括.NET和Java。

Answer 2

MD5的替代方案是MD6 Hash Algorithm但it is not ready yet 同时，这是a good read on secure hashing from Bruce Schneier。

另外，请查看NIST cryptographic hash project和
他们的tentative timeline of development of New Hash Functions
最近的另一次讨论 - SHA-3 Second Round Candidates Released，2009年7月

Answer 3

选择密钥大小时，NIST Special Publication 800‑57 (Part 1)，§5.6是一个有用的指南。信用卡行业的建议是“强”安全性，我将其解释为112“安全性”或更好。 NIST指南显示，对应于对称密码的三重DES（或小型高达128位AES）和RSA的2048位密钥。有关粗略等效的信息，请参见表2.

对于哈希算法，它取决于应用程序。如果您不需要与广泛部署的加密应用程序进行互操作，请尝试使用SHA-224或更高版本。但在某些情况下，互操作性可能需要SHA-1，尽管它很容易受到碰撞攻击。

Answer 4

Flickr签名方案完全破裂。永远不要使用它。

http://netifera.com/research/flickr_api_signature_forgery.pdf

Answer 5

您的服务有多安全？如果有人暴力破坏钥匙，会发生什么？如果您真的担心，为什么不使用SSL和客户端证书？

在您决定最佳加密方法之前，这些是您需要为特定项目回答的一般问题。

案例研究：在我正在开发的应用程序中，我使用DES（是的，普通DES）加密（而不是哈希）密钥数据，并由服务解密。所有URL都必须由服务器生成，该服务器保存共享密钥。有一个可选的时间戳来限制URL的有效性：如果您使用过期的URL访问服务，则会返回403。所讨论的数据价值相对较低，如果加密被破坏，则不会受到信托考虑。

可以被消费者设备打破吗？肯定。

打破它有很高的回报吗？完全没有。

为什么不直接以明文发送数据？因为我们希望确保某种程度的控制。我的主要目标是保持脚本小子不会通过持续插入/更新来创建拒绝服务攻击。

顺便提一句，明文中的数据永远不会出现在客户端和服务器之间的任何其他地方。这意味着，即使有人蛮力强迫密钥，他们也必须应用某种启发式方法来了解他们已经破坏了密钥。安全是通过Obscurity，是的，但有时默默无闻是有用的。